Kubernetes (k8s) is a portable, extensible, platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It provides exposing container, load balancing, volume storage, auto rollouts and rollbacks, distributes physical resources, self-healing and protects all your configuration. Kubernetes aims to microservices, itself not monolithic, default solutions are optional and pluggable. It also aims to support stateless, stateful, and data-processing workloads.
In this post, we will aim to deploy a Vuejs application very QUICKLY using Gitlab and Kubernetes. For more professional, you can using some tools like Helm (k8s package manager), Vault by HashiCorp (to protect sensitive data) and Prometheus — a monitoring and alerting toolkit. OK, let’s in.
Yarn as package manager (You may use npm, as well)
Setup a kubernetes cluster on your infrastructure (Read this doc or using cloud service like GKE or EKS). Save the .kubeconfig file, it’s used to authenticate with kubernetes API server.
# Run 'yarn build' to see the dist
COPY /dist /usr/share/nginx/html
CMD [ "nginx", "-g", "daemon off;" ]
3. Next step, create some .yaml files. It’s is a parameter send to k8s API server. Server will use resources and setting all up as your config. It pulls image that created above from Gitlab container registry using imagePullSecrets. I’ll show you how to create secret to authenticate with Gitlab.
// deploy token can be created in Gitlab settings. I'll show you later
Add secret you have just created (YOUR_SECRET_NAME) in .yaml below under imagePullSecrets. To run a web application, we need to use 2 resources: Deployment and Service. Let’s specify some concepts:
Pod: Pod is the basic execution unit of a Kubernetes application — the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on cluster. It is a group of one or more container (one is common), with shared storage/network, and a specification for how to run the containers. Pods serve as unit of deployment, horizontal scaling, and replication. Pods are mortal, they have life cycle and can be created, managed by Deployment, StatefulSet, DaemonSet.
Deployment: Deployment provides declarative updates for Pods. You can understand simply that Deployment controls Pods.
Service: An abstract way to expose an application running on a set of Pods as a network service. Remember, pods are mortal. If a pod die, Deployment will create a new pod with new IP address. So, how other dependent components find out and keep track of which IP address (changed) to connect to? Service is solution.
You can read more about concept and motivation of Deployment here and Service here.
- protocol: TCP
targetPort: frontend-port # max 15 characters
matchLabels: # help Deployment finds which Pods to manage
replicas: 2 # Deployment creates 2 replicated Pods
- name: my-frontend-container
image: "FRONTEND_IMAGE_TAG" # will be replaced later by Ci
- name: frontend-port
- name: YOUR_SECRET_NAME
To expose HTTP and HTTPS routes from outside the cluster to services within the cluster, an alternative is Ingress. You must install Ingress Controller before using Ingress. In this guide, I use Nginx Ingress Controller, to install it, follow this docs.
I highly recommend you install Runner in container using Docker image because some reasons. Imagine that your company has 2 projects building at the same time and only have 1 Runner (same environment), it’s easy for conflict. When using image, Gitlab will run 1 container per build. Please install and register Runner to your project follow this docs.
4.2. Second, create the deploy token I’ve told above:
Log in to your GitLab account.
Go to the project (or group) you want to create Deploy Tokens for.
Go to Settings > Repository.
Click on “Expand” on Deploy Tokens section.
Choose a name, expiry date (optional), and username (optional) for the token.
Save the deploy token somewhere safe. Once you leave or refresh the page, you won’t be able to access it again.
4.3. You almost done. Be patient. Gitlab also support custom variables. You should put secrets, sensitive data here instead of putting them in .gitlab-ci.yml. You can save .kubeconfig (base64), as well: