Opera #4: Docker
In this course, each of the groups are required to deploy to Fasilkom’s Docker registry and engine aside from the production environment provided by each of the partners. We are using Angular as the front-end web framework and various AWS services as the back-end, so we only need to containerized the Angular app. Let’s see how we do it so far.
Docker Container
Container is a term for a packaged application that bundled together with it’s dependency, runtime, and environment. The current most popular and widely used container is Docker, it has become the staple container everywhere. Here in this project, we use Docker to containerized our Angular application so it can be easily deployed to Fasilkom’s engine.
Building a Docker image
In order to build a Docker image, One must create a Dockerfile file which basically contain the “recipe” on how to create the image. Generally, it consist of what base image to be used as the runtime and then how do you want your apps to be put in the image. Here is our Dockerfile…
The script can be separated into two parts, build and package. Firstly, we use a Node based image since angular is a Javascript framework, we need npm which is part of Node to build our image. Then we are using the Alpine version of it. Alpine is a lightweight and small Linux distribution. Then we change the working directory and also copy all the source code into the image, keep in mind that some files will get ignored according to the .dockerignore file. We use npm install command to install all the dependency. Since Angular is a front-end framework, it needs to be compiled into html, css, and js files, we will use npm build for that.
Since it has been compiled, we don’t need the Node environment anymore, instead, we will use Nginx as the web server to serve our compiled resources. Alpine still be used as the runtime since it is berry good. Since we build our Angular app inside the previous image, we need to copy the compiled resources from that image using COPY and the argument --from=builder into the appropriate folder. We assigned the port to port 80 since it is the default port for HTTP request. We also add the ENTRYPOINT to tell docker what to do when running the image.
Using GitLab CD to deploy our image
Fasilkom also has their own GitLab instance and runners, we are going to use this as the means to continuously deploy our app. In order to use GitLab’s CI/CD pipeline, one must create a .gitlab-ci.yml file as the script. Here are ours…
Our script is way simpler than the other teams since we only need to deploy our front-end. Here you can see that our script has two main stages which is the test stage and deploy stage, I’m not going to elaborate on the test stage because that’s for another topic. In the deployment stage, we are using the Docker image, a Docker in Docker that allow us to do Docker stuff inside Docker. Most of these commands are only there as the workaround to get Docker in Docker (DinD) running in Fasilkom’s GitLab instance. The only important ones are the commands inside script.
To speed up our image building, we can pull the previous (if exist using || true) image to serve as the cache using docker pull and then reference it when building using --cache-from. Our registry has naming convention, so we tag our image appropriately when building it. Finally we can push our image.
Done diddly do
We have finally pushed our image to the registry. Later if you want the image to be able to be accessed, we can set up a container using the convenient Portrainer as the GUI for docker manager.
Thank you for reading this blog, have a great day!
