DEV Community: mixth

Ability to change configuration after build. For containerized Angular and more

mixth — Tue, 23 Jul 2019 17:32:08 +0000

It is pretty normal to encounter an application that requires multiple environment configurations. But when it comes to web, we tend to build a whole new app once again when we change just the environment configurations. And the process takes minutes.

In the world of containerization, this strategy of building everything makes it difficult to achieve one image, deploy everywhere, which I am such a fan of. And when someone tries to do so, it always makes a BIG image with building tools and so on. Plus, a long starting time for the containers too.

So my goals here are:

We can build once and deploy everywhere.
We can have a small final product image.
We can have the ability to change those environment configuration just at the deployment time.

With a simple web concept, we can achieve that.

GLOBAL VARIABLES!!!!

Yep... you heard it right.

I plan to put <script> in the <body>. Inside this <script>, I want to declare a global variable which is a simple object contains configuration of the environment. But, I am not going to put it in the index.html yet. Let's put a placeholder, say , instead.
In configuration file (such as what we have in typical Angular projects), I implement it to read global variable first, or else, assign a default configuration.
Add a new sed command for docker image. Which basically do just replace the placeholder with a config from environment variables.

Just that. We are good to go! Here are gists just for an idea.

Cons?

The config is plainly exposed.

This might let some users making weird things to your web. But I guess, it gonna have just a minimal impact since if they look hard enough, they might find it in any scenarios. Anyway, please proceed with caution.

That's it! Thanks for reading 😁
If you have any questions or some kind of improvement, please let me know in the comment below.

[GitLab Runner] Build Docker Image in Docker Job on GitLab Runner Container

mixth — Wed, 01 May 2019 10:23:05 +0000

It would be really awesome if we can run each jobs in Gitlab Pipeline in containerized environments. Gitlab Runner enables that by having image in targeted jobs accompanying with docker executor.

But... what about running these jobs in Gitlab Runner that is also running inside its own container? And then, build, tag, push Docker images as a job too?

Oh, yes! We can.

Why?

Because isolation each job to its container is sooooooo good. It creates a clean working space each time we run, we can also choose which environment we want to run each job simply by selecting a Docker image we want.

And having Gitlab Runner runs as container is pretty cool, right? We can easily start and upgrade it.

How about the part of building and pushing inside a container, you may ask. that part... I just want to try out making every job using container. That's all. 🤪 If you can think of any reason, please help me in the comment.

Steps

Here are the steps we will be doing today:

Prepare How To Start the Runner
Register the Runner
Start It!

Prepare How To Start the Runner

I usually use docker-compose to run Docker container declaratively.

version: "3"
services:
  runner:
    image: gitlab/gitlab-runner:alpine
    restart: always
    volumes:
      - /Users/zarewoft/gitlab-runner/config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock

First, I map my config directory to consume config.yoml that will be created later.

Secondly, docker.sock is mapped to accommodate Docker executor. This will make the executor interacts with host's Docker daemon, hence, its jobs will create containers that will be siblings of the Runner.

Register the Runner

The Runner requires to be registered with Gitlab server. Here, we will start a short-lived Gitlab Runner container to do just that. It will register to Gitlab server and create config.yoml to use in the future.

docker run --rm -v /Users/zarewoft/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner:alpine register -n \
   --url https://gitlab.com/ \
   --registration-token REGISTRATION_TOKEN \
   --executor docker \
   --description "My Docker Runner" \
   --docker-image "docker:stable"

command to register our Runner

From the example, I mount my config directory to persistently store config.yoml, same spot as what my earlier docker-compose will consume. I also provide docker-image which tells the executor what the default image is.

Cache Image Layers

Imagine define a job in Gitlab Pipeline. The job will build and push a Docker image which contains our app. It will definitely use image similar to docker:stable. In the process, it will create many layers of Docker image which can be reused in the future, sadly, it would destroy along with the job's container.

No. We shall not sacrifice minutes in each pipeline we run!!!
It would be nice if we can persist those layers somewhere 🤔.

Oh, or we can just make them use the host's Docker daemon!

Here comes docker-volumes. The option tells Docker daemon, which is the host's, to map docker.sock of the host to each container it will create for any jobs.

By adding this, our final register command look like this:

docker run --rm -v /Users/zarewoft/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner:alpine register -n \
   --url https://gitlab.com/ \
   --registration-token REGISTRATION_TOKEN \
   --executor docker \
   --description "My Docker Runner" \
   --docker-image "docker:stable" \
   --docker-volumes /var/run/docker.sock:/var/run/docker.sock

a diagram to make this article a bit more colorful

Start It!

And then, just up the docker-compose.

docker-compose up -d

Hope you find this informative enough. If there are any mistakes, please let me know in the comment. Thanks! 😊

สร้าง Docker Image ลีนๆ ด้วย Multi-stage Builds

mixth — Wed, 01 May 2019 06:51:07 +0000

Firstly published on 2018-01-18 in Medium.

สวัสดีครับ 😀
บล็อกนี้เป็นบล็อกแรกสำหรับเรื่อง Docker เลยครับ โดยผมตั้งใจว่าจะมาเล่าผลลัพธ์จากประสบการณ์การฝึกใช้งาน Docker ทั้งเรื่องง่ายๆ เรื่องที่เสียเวลา เรื่องที่เจ็บมาเยอะๆ ให้ทุกท่านอ่านกันครับ

"ขนาดไม่ใช่เรื่องสำคัญ" คงไม่จริงแน่ๆ สำหรับการใช้งาน Docker เพราะเมื่อขนาดใหญ่ขึ้น เราก็เสียค่า storage สำหรับเก็บ image ใน registry มากขึ้น ตอนรัน container ก็ต้องใช้ disk ของเครื่อง host มากขึ้นอีก

การลดขนาดของ docker image มีหลากหลาย practice ที่เราควรทำครับ เช่น การไม่พยายามสร้าง layer ใหม่ที่ไม่จำเป็นด้วย RUN, การจัดวาง sequence ของ command ใน Dockerfile
วันนี้ผมจะพาท่านๆมารู้จักกับ multi-stage builds ซึ่งผมได้ความรู้มาจากการลองผิดลองถูก อ่านบทความต่างๆ แล้วทดลองใช้กับงานจริงครับ

Multi-stage Builds

ผมมักชอบที่จะรัน test และ build บน docker เลย เพื่อการันตีว่าแอพผ่านการ test ก่อนจะ build บน environment ที่เหมือนกันครับ แต่ในบางครั้งการ build บน docker ก็ทำให้มี file ที่ไม่จำเป็นมากมายเกิดขึ้นใน image เรา ถ้าเราเอาตัวนี้ไปใช้จริงก็คงจะเป็น image ที่หนาเกินไป

ยกตัวอย่างเช่น build gulp สำหรับ frontend แอพ ถ้าเอาแบบเอี่ยมๆเลย เราก็ต้องใช้ FROM node แล้วมา npm install แล้วค่อยใช้ gulp อีกที

ซึ่งมันไม่จำเป็นมากๆเลยที่จะเอาทั้งหมดนี้ไปไว้ใน image ใช่ไหมครับ เพราะสุดท้ายแล้วเราแค่จะ serve static file เอง มันคงจะดีไม่น้อย ถ้าเราใช้ image หนึ่งอันมารันทั้งหมดนี้ แล้วเอาผลลัพธ์ไปใส่อีก image ใช่มะ?

Multi-stage builds คือ concept แบบที่เราว่าเลยครับ กล่าวคือ การสร้าง stage นึง แล้วใช้เป็นแค่ทางผ่านแล้วเอาไฟล์ไปใช้อีก stage นึงครับ

วิธีการใช้งาน

ระบุ name ให้กับ image ที่เราสร้างในกระบวนการในบรรทัด FROM

FROM <IMAGE> AS <NAME>

เวลาเราจะ COPY file จาก stage เดิม ให้ใส่ parameter ชื่อ from เพิ่มเข้าไป

COPY --from=<NAME> <ORIGIN_PATH> <DEST_PATH>

ตัวอย่าง multi-stages builds โดยการ npm install, run build แอพ ก่อนจะสร้าง image nginx สำหรับ serve

ในตัวอย่างข้างต้นคือเราใช้ image node มา build app เสร็จแล้ว serve ด้วย nginx ครับ ถ้าอยาก validate ดูว่าถูกต้องไหม ลองสั่ง docker history <IMAGE_HASH> ดูได้ครับ
แต่หากเราไม่อยากตั้งชื่อให้มันจริงๆ ก็ใส่เป็น index ก็ได้นะ (0, 1, 2, …) โดยเรียงจาก FROM ด้านบนสุดมาเรื่อยๆครับ (แต่… มันตั้งชื่อได้ก็ตั้งให้มันเถิด)

ลองดูนะครับว่าเราสามารถใช้เทคนิคนี้ในการทำให้ image ของเราเล็กลง หรือใช้งานได้สะดวกขึ้นอย่างไงบ้าง

หากมีส่วนใดผิดพลาด ไม่ถูกต้อง แจ้งได้เลยครับ :)