Scaling containers on Kubernetes with Replicatsets or scale services with docker swarm is a very easy task! but what about scaling containers in a non managed environment, when you have high traffic, absolutely you need to scale and load balance the traffic among multiple containers. In this article, we will use Ansible and nginx to scale containers.

Setting up the environment

Before starting make sure you have the required packages:

• Ansible 2.9: pip install ansible
• Docker latest : follow this link to install docker
• Docker python package installed on the remote host: pip install docker
• A ubuntu machine (18.04)

Let's Code!

In this section, we will attach the puzzle pieces, we will test everything locally, but the actual aim of this setup is to integrate it into the pipeline, so we can put the scale number and deploy it if you don't want to make it in the CI/CD pipeline, it's ok you can just launch the playbook against the server and scale your container (don't forget the container name), automatically will scale the containers and update the nginx config.

Inventory file

The inventory file will hold our variables and the target where we can execute the task, it contains two host children (network and clean) derived from the main host (local)

[local]
localhost ansible_connection=local
[local:vars]
scale=5
c_name=<container-name>
h_name=<container-name>
subnet=172.16.0                                           
network_name=network
image_name=<image-name>
[network:children]
local
[clean:children]
local

The most important variable is scale, it's the number of containers that will start in the host, the other variables are about the container name, the image, and the subnet where the containers will run.

Ansible playbook

The ansible-playbook will hold all the logic of what we will do here. the inventory files variables will be accessible to the playbook

Creating the network

This task will create the network with the specified subnet and the gateway, note that the network will be created if doesn't exist, otherwise, the task will be skipped

- hosts: network
  tasks:                                                     
  - name: Create docker network
    docker_network:
      name: "{{ network_name }}"
      ipam_config:
        - subnet: "{{ subnet }}.0/16"
          gateway: "{{ subnet }}.1"

Getting the last scale number

Based on the image name we can get the number of containers actually running, to do that we used a shell script the gather that information. The set_fact will create a variable dynamically that will be accessible to the whole playbook by registering the output of the script and get the stdout as a JSON format.

  - name: get last scale
    script: ./get_cont_num.sh {{ image_name }}
    register: last_scale

  - set_fact: 
      last_scale={{ last_scale.stdout }}

  - debug: var=last_scale

We can debug the variable content by adding the debug keyword and print it out.

#!/bin/bash 

docker ps -f ancestor=$1 --format '{{.Names}}' | wc -l

This bash script will give us names like this name_1,name2 ..etc so we can count it with the word count command wc the line option.

Starting the container

Starting the container with the actual number specified in the scale variable, looping into it with the with_sequence and index the counter with item, For the ipv4_address it starts from 2 because the first one is for the gateway.

 - name : starting containers
    docker_container:
      name: "{{ c_name }}_{{ item }}"
      image : "{{ image_name }}"
      pull: yes
      restart_policy: always
      hostname: "{{ h_name }}_{{ item }}"
      networks:
        - name: "{{ network_name }}"
          ipv4_address: "{{ subnet }}.{{ 1+item|int }}"
      purge_networks: yes
    with_sequence: start=1 end="{{ scale }}"

If you have many containers on the network make sure to separate the IPs (host ID) with al least 5 like this :

Frontend : 172.16.0.2
Backend: 172.16.0.8
...

To be able to scale each container and don't make an IP conflict when scaling.

Removing container

In this task, we will remove the unneeded containers, it starts only when the scale number > last scale otherwise the task will be skipped. but we have to make things clear on the with_sequence logic because it will be compiled but not executed when skipping.

  - name : down-scaling uneeded containers 
    docker_container: 
      name: mongo_{{ item }}
      state: absent
    with_sequence: start="{{ last_scale|int if (last_scale|int - scale|int)|abs == 1|int  or last_scale|int == scale|int  or scale|int > last_scale|int else 1+scale|int  }}" end="{{ last_scale }}" 
    # last_scale=4 scale=2
    # last_scale=3 scale=3
    # last_scale=3 scale=4 
    # last_scale=2 scale=4
    when: scale|int < last_scale|int

The logic says that if : ==> return last_scale if

• Positive(last_scale - scale) == 1 or
• last_scale == scale or
• scale > last_scale else
• return 1 + scale
  This logic can ensure removing the right number of containers without mistakes

Getting containers IPs

In this task we will get all IPs of our scaled containers. The set fast will contain all IPs by filtering the output from register by splitting with r\n to get a loopable list

  - name: generate  ip 
    script: ./get_name_ip.sh {{ scale }}
    register: last_scale

  - set_fact: 
        list_ip={{ last_scale.stdout.split("\r\n")|list }}

Depending on the scale number we can loop over the container names (name_1,name_2) and get all IPs associated with every container.

#!/bin/bash
scale=$1

for i in $(seq $scale) 
do
docker inspect container_$i | jq ".[].NetworkSettings.Networks.network.IPAddress" -r
done

Generating nginx.conf file

Thanks to the set_fact all variables that are created in the playbook dynamically will be exposed by default to the jinja2 template so we can use it easily.

  - name : generate file 
    template : 
        src: example.domaine.com.conf.j2
        dest: example.domaine.com.conf

The template module will generate a new nginx.conf depends on the scale number, I mean if we have scale=1 we will generate a simple configuration, otherwise, we will make the load balancing configuration with the containers IPs

{% if  scale > 1 %}
upstream manager {
{% for i in range(scale) -%}
server http://{{ list_ip[ i ] |ipaddr }};
{% endfor %}
}
server {
        listen 80;
        listen [::]:80;
        server_name admin.domaine.com;
        return 301 https://$host$request_uri;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name admin.domaine.com;
        ssl on;
        ssl_certificate /etc/letsencrypt/live/admin.domaine.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/admin.domaine.com/privkey.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
        location / {
                include /etc/nginx/extra.d/caching_ht.conf;
                proxy_pass http://manager;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade; # allow websockets
                proxy_set_header X-Forwarded-For $remote_addr; # preserve clien$
                proxy_set_header Host $remote_addr; # preserve client IP
        }
}
{% else %}
server {
        listen 80;
        listen [::]:80;
        server_name admin.domaine.com;
        return 301 https://$host$request_uri;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name admin.domaine.com;
        ssl on;
        ssl_certificate /etc/letsencrypt/live/admin.domaine.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/admin.domaine.com/privkey.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
        location / {
                include /etc/nginx/extra.d/caching_ht.conf;
                proxy_pass http://{{ list_ip[0]|ipaddr }};
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade; # allow websockets
                proxy_set_header X-Forwarded-For $remote_addr; # preserve clien$
                proxy_set_header Host $remote_addr; # preserve client IP
        }
}
{% endif %}

For the SSL configuration, you can make sit easily by running the certbot command and get your certificate, note that this configuration is applied to the frontend containers because we have SSL, you can apply it to your backend easily and update the nginx configurations easily.

Applying the nginx configuration

This task is trivial, we just checking nginx syntax and reloading configurations, if you want you can change the reload by restarting nginx.

   - name: Verify Nginx config
     become: yes
     command: nginx -t
     changed_when: false

   - name: reload Nginx config
     become: yes
     command: nginx -s reload
     changed_when: false

Cleanning

Clearing unused containers and volumes or images with no tags is a best practice for making your server in a good mood :)

- hosts : clean
  gather_facts : no 

  tasks: 

  - name: Removing exited containers
    shell: docker ps -a -q -f status=exited | xargs --no-run-if-empty docker rm --volumes
  - name: Removing untagged images
    shell: docker images | awk '/^<none>/ { print $3 }' | xargs --no-run-if-empty docker rmi -f
  - name: Removing volume directories
    shell: docker volume ls -q --filter="dangling=true" | xargs --no-run-if-empty docker volume rm

I'm integrating this solution on my CI/CD because to scale when I push my code, it's simple and needs more work to be generic and reliable, you can find all the files on Github repository. The demo gif on the repository I test it with mongo, I know that we cannot scale databases like this actually, I'm jus treating it as a container that's it.

I was working with Kubernetes and I just want to check my pods in the current workspace, in a funny way 😅, I will use bash for just one reason, it's the Linux native languages no need for other languages and libraries

Actually, I was inspired by a cool tool called popeye, you can find it here.

Make sure you have Kubectl installed and an existing cluster as well, here is my implementation

• Define your favorite colors

blanc="\033[1;37m"
gray="\033[0;37m"
magento="\033[0;35m"
red="\033[1;31m"
green="\033[1;32m"
amarillo="\033[1;33m"
azul="\033[1;34m"
rescolor="\e[0m"

You can find more about colors in bash here.

• Get list pods into an Array

listPods=$(kubectl get po | awk 'NR>1{print $1}')
#echo "$listPods"
readarray  arr <<<  $listPods

NR>1 will skip the first line and print $1 will print the first words (separated by a space) on all lines.

• Looping over the array and check the status

ok=0
notok=0
echo -e "\nSit Down and Wait  \U1F602 :\n"
for i in ${arr[@]}
do 
echo -ne "$i ... " 
status=$(kubectl get po $i | grep $i | awk '{print $3}')
    if [[ ! $status =~ ^Running$|^Completed$  ]]  ; then
        echo -e "\e[1;31mOh Shit !"$rescolor""
        notify-send "Pods Health" "$i was  FUCKED" -t 10000 
        let notok=notok+1
    else
        echo -e "\e[1;32mOK!"$rescolor""
        #notify-send "Pod $i Is Good :)"
      let ok=ok+1
    fi
done

The ok and notok are used to count the number of the running/not running pods , the ${arr[@]} prints out the whole array, the notify-send will create a notification on your system is one of the pods are fked up** .

• Print out the summary

echo -e "\nSTATS:\n"
echo "+---------------+---------------+"
printf  "|$green%-15s$rescolor|$red%-15s$rescolor|\n" "Healthy Pods" "Unhealthy Pods"
echo "+---------------+---------------+"
printf  "|%-15s|%-15s|\n" "$ok" "$notok"
echo "+---------------+---------------+"
echo -e "\n"

• Run the script

Download the scripts with CURL :

curl https://raw.githubusercontent.com/hatembentayeb/podschecker/master/podschecker.sh --output podschecker.sh
chmod +x podschecker.sh

• Demo

Repository: https://github.com/hatembentayeb/podschecker

The scripts don't do much but it was a result of a boring 3 hours on this pandemic 🥲

In this post we will deploy a simple dockerized Machine learning application written with the Flask micro-framework to the Heroku (PaaS), using one of the leading CI/CD tools, which is Gitlab!, all used tools are free and no fees in achieving this tutorial.

Tools to know

This the list of tools that we need to achieve the aim of this tutorial alongside some bash scripting knowledge

Code base

Before starting let's understand what we will dockerize here! This application is a simple machine learning that exposes two routes :

• /kmeans: This route accepts a JSON data format with two entries. The first one is the number of clusters you want the classifier to consider, the second one is the text that we will group into the specified number of cluster, each group will contain words that are similar on the meaning or has the same area like people, building, civilization and so on.

• /ads : This route accepts also JSON data format that contains also two entries which are the age and the annual salary, the result will be if this person can buy a product on which he saw it on a social media.

The app used Two ML algorithms associated with routes :

1. KMEANS : Learn more
2. Liniar SVC: learn more

Here is the code :

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import KMeans
from sklearn.metrics import adjusted_rand_score
import json
import os
# Importing the libraries
import numpy as np
import pandas as pd
from flask import Flask,jsonify,request,render_template
app = Flask(__name__)


@app.route('/')
def main_page():
    return render_template('index.html')

@app.route('/kmeans', methods=['POST'])
def kmeans_pred():
    posted_data = request.get_json()
    true_k = posted_data['num_cluster']
    documents = posted_data['data']
    feeds = dict()
    vectorizer = TfidfVectorizer(stop_words='english')
    X = vectorizer.fit_transform(documents.split('.'))
    model = KMeans(n_clusters=true_k, init='k-means++', max_iter=100, n_init=1)
    model.fit(X)
    order_centroids = model.cluster_centers_.argsort()[:, ::-1]
    terms = vectorizer.get_feature_names()
    print(terms)
    for i in range(true_k):
        feeds.update({"cluster_"+str(i)+"": [terms[ind] for ind in order_centroids[i, :10]]})
    return jsonify(feeds)

@app.route("/ads", methods=['POST'])
def purshase():
    posted_data = request.get_json()
    age = int(posted_data['age'])
    salary = int(posted_data['salary'])
    new_data = [[age,salary]]
    # Importing the dataset
    dataset = pd.read_csv('Social_Network_Ads.csv')
    X = dataset.iloc[:, [2, 3]].values
    y = dataset.iloc[:, 4].values
    # Splitting the dataset into the Training set and Test set
    from sklearn.model_selection import train_test_split
    X_train, X_test, y_train, y_test = train_test_split(X, y, test_size = 0.25, random_state = 0)
    # Feature Scaling
    from sklearn.preprocessing import StandardScaler
    sc = StandardScaler()
    X_train = sc.fit_transform(X_train)
    X_test = sc.transform(X_test)
    new_data_pred = sc.transform(new_data)
    # Fitting SVM to the Training set
    from sklearn.svm import SVC
    classifier = SVC(kernel = 'linear', random_state = 0)
    classifier.fit(X_train, y_train)
    # Predicting the Test set results
    y_pred = classifier.predict(new_data_pred)
    response = {
        "result" : str(y_pred)
    }
    return jsonify(response)

if __name__ == '__main__':
    app.run(host="0.0.0.0", port=os.environ.get('PORT'))

I will not explain the code, it's not the aim of this tutorial. But take a look a the last line :

    app.run(host="0.0.0.0", port=os.environ.get('PORT'))

The app takes an environment variable called PORT ... but Why?

When you log in to your Heroku pannel you will create a simple server with a custom name, that name will be used later to access the app via the internet, in-depth it is a subdomain linked to your app, it's much like an nginx reverse proxy that will point the subdomain to you deployed app, How?

Simply, When you hit the subdomain, Heroku will route your request to that port and return a response. If you choose your own port, your app won't work, because he doesn't know where to access the container.

Ship the app

It's time to ship the app into an isolated container to be shippable on any Server!

FROM frolvlad/alpine-python-machinelearning
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
EXPOSE 3000
ENV ENVIRONMENT dev
COPY . /app
CMD python main.py

This image frolvlad/alpine-python-machinelearning is ready to go image that contains what we need like the sklearn so we don't install it as a dependency, then we set our work directory to /app and copy the requirements.txt file to be used by the pip command to install Flask. By default, the app will run on port 3000 if we set the port on the app.run(host='',port=''). besides we need to copy the rest of the app code and run it with python main.py.

Test it locally

To test locally follow these steps :

# Clone the project 
git clone https://gitlab.com/hatemBT/REST-API-KMEANS
# Run it locally 
pip install -r requirements.txt
# Run the code 
python main.py
#To build the docker image (change the  port=os.environ.get('PORT') => port=3000 (you can choose yor custom port))
docker build -t kmeans_app . 
#Run with docker 
docker run -p 3000:3000 kmeans_app

Make sure to install python3 and docker engine.

Prepare your Server

Log in to your Heroku account and then create a new app and name it hello-devops-python and choose the region from US or Europe, choose the nearest to you, hit create!

Notice that your app URL will be hello-devops-python.herokuapp.com.

We need the API key now, go to settings and grab that key.

We need to create a special file called .netrc that will allow us to connect to Heroku API and it's Git :

machine api.heroku.com
  login <mail>
  password <apiKey>
machine git.heroku.com
  login <mail>
  password <apiKey>

Gitlab pipeline

Make sure to have a GitLab account and a repository

We need to put the apiKey and the Heroku registry URL in GitLab as secrets. go to settings->CI/CD->variables and add HEROKU_APP=registry.heroku.com/hello-devops-python/web, note that web is the container name. and HEROKU_TOKEN that hols the API key.

The pipeline has a single-stage development that will deploy the container to the "hello-devops-python" app. Let's write the CI/CD configuration (.gitlab-ci.yml) :

image : docker:latest
services:
  - docker:dind
variables:
    DOCKER_DRIVER: overlay
stages:
    - development
devloppement:
    stage : development
    script:
         - docker build -t $HEROKU_APP .
         - docker login --username=_ -p $HEROKU_TOKEN registry.heroku.com
         - docker push $HEROKU_APP
         - docker run  --rm  -e HEROKU_API_KEY=$HEROKU_TOKEN wingrunr21/alpine-heroku-cli container:release web --app hello-devops-python

Simply this pipeline follows these steps :

• Build the container: docker build -t $HEROKU_APP .
• login to Heroku registry: docker login --username=_ -p $HEROKU_TOKEN registry.heroku.com
• Push the container: docker push $HEROKU_APP
• Release the container: docker run --rm -e HEROKU_API_KEY=$HEROKU_TOKEN wingrunr21/alpine-heroku-cli container:release web --app hello-devops-python, we used a temporary docker image that contains the heroku-cli pre-installed, to deploy the web container to hello-devops-python.

Push the code Wait unit Green

Test The App

You can access your app now via the browser, let's test the app API :

Test the /kmeans route :

curl -X POST -H "Content-Type: application/json" "http://hello-devops-python.herokuapp.com/kmeans" -d @data.json | jq "."

Example data :

{
    "num_cluster":2,
    "data":"
The brothers wanted to build their own kingdom where people could live without fear.
 They collected a band of young men and trained them in warfare
 They lived in a forest hideout on the banks of the river Tungabhadra in South India.
One day, the brothers were out on a hunt. Ferocious dogs accompanied them.
 They crossed the river and rode on 
A couple of frightened rabbits ran out of the bushes
The dogs gave them chase with the two brothers closely behind on their horses.
"
}

Output:

{
  "cluster_0": [
    "accompanied",
    "ferocious",
    "dogs",
    "gave",
    "forest",
    "fear",
    "day",
    "crossed",
    "couple",
    "collected"
  ],
  "cluster_1": [
    "brothers",
    "hunt",
    "day",
    "river",
    "wanted",
    "fear",
    "people",
    "build",
    "live",
    "kingdom"
  ]
}

Test the /ads route :

curl -X POST -H "Content-Type: application/json" "http://hello-devops-python.herokuapp.com/ads" -d "{\"age\":80,\"salary\":190000}" | jq "."

Output :

{
  "result": "[1]"
}

The presentation version :

Building binaries on compiled languages like Rust and Go as Static or dynamic linking makes a huge step on code security, I mean no one can access your code, reading it !, but in many use cases they can by doing some complicated reverse engineering methods ... actually it's hard! it becomes harder when you built your app as a static linking and bundle all the shit 💩 together. Nodejs applications can be read it easily ... all your source code is accessible, In this post, we will hide our node app and "COMPILE" it! seems awesome right! let's go folks 😇 !

Get the app

You need to have nodejs installed to test the app locally, I tested the app on node 12.2.0. You might have some problems with the database so make sure to use the appropriate mongoose version that is compatible with MongoDB, I have mongoose 5.10.10 that is compatible with mongo 4.4. Let's run the app 🤓 !

Clone the code

Make sure you have Git installed!

git clone https://github.com/hatembentayeb/node-rest-api-mongo.git 
cd node-rest-api-mongo
npm install

Run a mongo instance

make sure you have docker installed, otherwise install mongo directly.

docker run -p 27017:27017 --name mymongo -d mongo:latest

Modify the .env file

On the mongo uri we have the ip of the mongo container, you can use localhost:27017 instead, but we need the IP when we run the app inside the container.

PORT=3000
MONGODB_URI=mongodb://172.17.0.3:27017
DB_NAME=hatem

Run the app

You can run it with node app.js

npm start

Insert data

Using curl with POST request to send data inside the products.json. the jq command is just for formatting JSON.

curl  -X POST -H "Content-Type: application/json" "http://localhost:3000/products" -d @products.json | jq

Get data

Simple GET request to get all requested data

curl http://localhost:3000/products | jq

Why we need a binary

This approach! i mean building binary can save us especially to get rid of the node_modules inside our container! we will save space and enhance the image size! besides we don't need any base node image like FROM node: latest because it's just a binary that needs a shell to run, also you have to make a choice of your build platform or architecture, you can find the full list of the available architectures for nexe on this link full list.

In this tutorial, we need a minimal docker image ... like 5MB of size ! , that's awesome ! yes, it's is the alpine image, the smallest one! now we can deploy a docker image with a low size! it will be extremely fast believe me, if you have a small server with limited os storage or an on-premise docker registry with limited storage it will be wonderful to store images with small size !!

If you try to build the project with nexe and then use it on a docker container based on alpine, it will work !, only in your dreams 🤣. To be able to run it on alpine we need to set the right architecture platform before the build.

In terms of security, you are almost secure they can't get to your source code! it's a binary! dude, but they can access your container if they succeeded to create shell access with the RCE (remote code execution) attack ... they can do it by attacking your application and exploit it, so they are on your container now! they can't read your code but they can crash your container and access your host and here is the disaster 😳 ! so I will try to limit the privileges on the container by disabling the root access and create a non-root user and remove some of the default Linux commands like ls, cat and mv 😈.

Anyways, let's start building binaries 😋

Let's build it

In order to build the binary, we need a special package called nexe with over then 9k stars on GitHub 🧐 !!

To install it run this command npm install -g nexe and check the package version nexe -v, I have the 4.0.0-beta.16 version.

To build the application just run this command! :

next app.js -t alpine-x86-12.2.0 -o mybinary

let's breakdown the nexe options :

• app.js: is your application entry point
• alpine-x86-12.2.0: is the node version that is compatible with the alpine architecture platform with is x86
• mybinary: is your binary output file that we will copy to the container.

In some cases you need to bundle some HTML files to your binary or any some directories, you can do that by adding the --recursive/-r option and specify the path like this :

nexe app.js -t alpine-x86-12.2.0 -r static/**/*.html -o mybinary

Alright let's run the binary :

$ ./mybinary 

Server started on port 3000...
Mongoose connected to db...
Mongodb connected....

And here we go! it's much like a command! try to move it to another location on your file system and run it again! awesome it works smoothly, congrats! you have a standalone binary for your node app 😍 !

Move it to docker

let's run the app with docker, we need a dockerfile to build the image, here is an example:

FROM alpine
WORKDIR app
RUN adduser --disabled-password btx
RUN rm -f /bin/cat /bin/ls /bin/mv /bin/find /bin/cd 
COPY hatem .
COPY .env .
EXPOSE 3000
RUN chown -R btx:btx /app
USER btx
CMD  ["./mybinary"]

We will base the container on a lightweight docker image: Alpine it's about 5MB in size! then we define our working directory /app to be the default directory for the rest of all commands and when you access the container via exec. Adding a non-root user called btx without a password and remove some of the basic Linux commands like ls , cat , mv , find and cd. Now no need to copy the whole project 🥲, just that tiny binary! and that's it. We know that the app depends on a .env file so we copy it inside the container.

Exposing the container port is dependent on the port number on the .env file. Now all artifacts are in the right place, so now let's change the directory ownership to the btx user and activate that user to be the default one when we access the container via exec. The final command is to start the app as a single process on the container.

Time to cook 😊

Build the docker image :

$ docker build -t node-api-crud:v1 . --no-cache

Run the docker image :

$ docker run -p 3000:3000 --name node-rest  node-api-crud:v1
Server started on port 3000...
Mongoose connected to db...
Mongodb connected....

We can now test the app and start inserting data and getting them via curl via localhost:3000

Final thoughts

To ensure more security test try to use :

• npm audit fix to fix any dependency vulnerability.
• Anshore for scanning the docker image and check if there is any critical CVE on the system packages.
• Trusted images from official docker hub repos, or make your own.
• Sonarqube to make some SAST and discover potential security issues on your code.

         You build it, you run it, you secure it

Setting up a full-featured mail server is an actual PAIN for a system admin, you have to interconnect many software pieces and a lot of testing especially security and spam if you plan to use it for your company ... In this Post, I will take you in my journey of setting up a full-featured mail server, I was searching a lot on the internet and I didn't get a sweetly answer to move on .. but finally I successfully made it! .. It works with multiple domains, secure, and no spam problems!

For the reader

I assume you have knowledge about how email works, Mail DNS records, Linux, docker, and SSL of course. This guide is not for beginners

If you don't have enough knowledge, take a seat and take a look here :

Mailcow

Mailcow is a free, open-source software project. A Mailcow server is a collection of Docker containers running different mail server applications, SOGo, Postfix, Dovecot, etc. Mailcow provides a modern and easy to use the web interface to create and manage email accounts. You can visit the official documentation

I ill not make a comparison about different opensource self-hosted mail servers, rather then that I will give you a great repo that includes awesome software marked as self-hosted, you can check the Email section come here

If you want some thoughts about mailcow from real users check these Reddit discussions: come here and here

Server Requirements

The recommended OS to run mailcow is ubuntu 18.04, also don't use cento7 packages on cento8 because the maintainers said :

Do not use CentOS 8 with Centos 7 Docker packages. You may create an open relay.

For the resources, I bought a VPS from OVH cloud provider with :

• 2 VCPU
• 4 GB of RAM
• 80 GB storage

Docker installed :

curl -sSL https://get.docker.com/ | CHANNEL=stable sh
systemctl enable docker.service
systemctl start docker.service

Docker-compose installed :

curl -L https://github.com/docker/compose/releases/download/$(curl -Ls https://www.servercow.de/docker-compose/latest.php)/docker-compose-$(uname -s)-$(uname -m) > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

If you have a firewall, you should allow those ports :

netstat -tulpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'

Note: you must have a clean server means no other applications or a reverse proxy because mailcow has everything in place.

Okay, now everything is good! but there is another thing to verify which is our IP !!! we have to test it if it is blacklisted, if yes it's a huge problem ... we can't proceed anymore because your mails will not be delivered, it's all about your host reputation!.

We can check it with an online service called MX toolbox by visiting this URL mxtoolbox.

Basic DNS configuration

Before we proceed we have to get a domain name from any provider, I got one from OVH, and I delegated it to AZURE DNS SERVICE, it doesn't matter actually, we will have the same configuration in any provider.

I pretend that i have :

• Root Domain name : mymailserver.com
• Server IP address : 1.2.3.4

Let's get started !

Create an A record

In your provider DNS panel add an A record like this

• Name : mail
• Type : A
• TTL : default
• Value : 1.2.3.4

You can confirm with the dig command :

 dig mail.mymailserver.com +noall +answer

Create the CNAME records

In your provider DNS panel add a CNAME record for the autoconfig like this

• Name : autoconfig
• Type : CNAME
• TTL : default
• Alias : mail.mymailserver.com

Test it with : dig autoconfig.mymailserver.com +noall +answer

Add another CNAME record for the autodiscover like this :

• Name : autodiscover
• Type : CNAME
• TTL : default
• Alias : mail.mymailserver.com

Test it with : dig autodiscover.mymailserver.com +noall +answer

Create an MX record

In your root domain add an MX domain to point to your mail server domain :

• Name : @/empty
• Type : MX
• TTL : default
• Prefenerence/periorty : 10 or 0
• Mail Exchange : mail.mymailserver.com

rDNS configuration

Get more information about rDNS here

You can configure your rDNS on the provider of your server and change the generated domain name to your mail domain mail.mymailserver.com

and test it with dig -x 1.2.3.4 +noall +answer, should get mail.mymailserver.com as responce.

Security DNS Records

Authenticate your mail server and protect it from Fake identities and Domain spoofing attacks we have to set up those records

SPF record

In your root domain add a TXT record like this :

• Name : @/empty
• Type : TXT
• TTL : default
• value : v=spf1 ip4:1.2.3.4 -all

Test it with dig mymailserver.com TXT

DKIM record

Setting up the dkim record needs a public key to be inserted in the record here but we can't now because we have to install mailcow and get the public key given by our mail server, we will leave it empty for now.

• Name : dkim._domainkey
• Type : TXT
• TTL : default
• value : v=DKIM1;k=rsa;t=s;s=email;p=

DMARC record

The best thing you can do for dmarc is to make a free account on dmarcian, it will give you a record like this :

v=DMARC1; p=reject; rua=mailto:<dmarc email1>; ruf=<dmarc email2>

Just add it to your domain DNS pannel like this :

• Name : _dmarc
• TTL : default
• value : v=DMARC1; p=reject; rua=mailto: dmarc email1 ; ruf=dmarc email2

The test is with: dig _dmarc.mymailserver.com TXT

That's it for the DNS configurations, all records are in place except the dkim value we ill add it later

Install mailcow

You need git installed to clone the repo in your server :

 git clone https://github.com/mailcow/mailcow-dockerized
 cd mailcow-dockerized

You in the repo now, so run the script ./generate_config.sh to generate your config, for the hostname add mail.mymailserver.com, it will request a certificate from Let'svEncrypt automatically.

To run your mail server just use this command :

docker-compose pull
docker-compose up -d

You need to wait sometime to download all the containers, run them and provision an SSL certificate.

The default credentials to access are admin & moohoo (you must change it with your own)

Verify that all containers are healthy with the green icon like this :

Well done! Let's proceed to add domains and mailboxes

Configure Mailcow

Our mail server is working now but there are neither domains nor mailboxes configured. in this section, we will go step by step .. let's GO!

Add your domain

Login to your mailcow admin panel :

1. Select configuration on the top bar then select mail setup
2. Click on add domain then add your root domain mymailserver.com and click on Add domain and restart SoGo
3. Select configuration again then click on configuration & details
4. In the horizontal menu click configuration and click on ARC/DKIM keys
5. Scroll to the bottom and fill the domain/s form with your domain mymailserver.com
6. On the selector type dkim
7. Select 2048 on the DKIM key length and click Add
8. Copy the generated public key that starts with v=DKIM1;k=rsa;t=s;s=email;p= ...
9. Go to your DNS panel and modify the TXT record with the generated value
10. Wait until your DNS modification propagate

You can validate your configuration for SPF, DKIM and DMARC with this site, you should get a result like this (don't forget to put dkim as a selector` :

Create a Mailbox for mymailserver.com

By default, mailcow give 10GB of storage to every domain and every mailbox under that domain has 3GB of storage .. so feel free to modify them to your needs,

To create a mailbox follow those steps :

1. Under configuration on the top bar click mail setup and select mailboxes`
2. Click add mailbox
3. Choose a username, your domain (it will be loaded automatically) and then add a password and click Add
4. On the top bar click apps and then webmail, you will be redirected to the SoGo UI, login with your newly created mail and password
5. on the bottom click on the green icon, you will get an interface for sending a mail
6. In your browser open another tab and go to this site: mail-tester.com and copy the mail address.
7. Return to your SoGo interface and send a mail with that mail, on the body make sure to add some text with a least two paragraphs.
8. Wait 10 seconds and go the mail-tester.com and click on then check your score

And BOOM you should get this result You Can Send :

Feel free to send a mail to your friends and your own Gmail address, don't worry Gmail still doesn't know your mail server, so he will place it as spam, just unspam it! try to send it to Zoho mail for example. The test again with other tools I suggest to use :

• Mxtoolbox SuperTool and select test mail server
• Dkimvalidator and send an email to the given address, make sure that all tests are passed like the dmarcian.com tests.

Add another domain to mailcow

I assume we have a second domain: myseconddomain.com. I will not repeat the same steps it's quite easy so let's go :

1. Create A record: mail.myseconddomain.com that points to your Host 1.2.3.4
2. Create a CNAME record: autoconfig that points to mail.myseconddomain.com
3. Create a CNAME record: autodiscover that points to mail.myseconddomain.com
4. Create an MX record: on the root domain add 10 as a priority and mail.myseconddomain.com as target
5. Create SPF record as we did earlier
6. Create a DMARC record as we did earlier
7. Create a DKIM record and at the same time add your new domain as we did earlier and copy the generated DKIM key to your DKIM record.
8. Validate your records
9. Add a mailbox under your new domain and send an email to mail-tester.com and dkimvalidator.com, you should get 10/10 sweetheart :)

Final thoughts

Don't send a lot of emails directly you will be blocked! ... so start step by step by sending 20 emails per day for the first week then try sending 80 the next week ... after 2 months you can send a lot of mails like 1000 emails, but take in mind that you need to add the list-unsubscribe headers to your postfix to allow users to unsubscribe against your newsletters/subscriptions.

please follow me on Twitter @hatem ben tayeb

In this article we will discover the DevOps movement step by step, we will talk about the fundamental concepts then we will make a basic pipeline with GitHub actions to deploy an Angular 6 app, so let’s go.

What is DevOps?

DevOps is used to remove the conflict between the developers' team and the operations team to work together. This conflict is removed by adding a set of best practices, rules, and tools. The DevOps workflow is defined with a set of steps :

Plan

This is the first step, where the team defines the product goals and phases, also defining deadlines and assigning tasks to every team member, this step is the root of the whole workflow. the team uses many methodologies like scrum and agile.

Code:

After planning, there is the code when the team converts the ideas to code. every task must be coded and merged to the main app, here we use an SCM to organize the collaboration to make a clean code and have a full code history to make a rollback in case of failure.

Build:

After coding, we push the code to Github or Gitlab ( SCM ) and we make the build, usually, we use docker images for packaging. also, we can build the code to be a Linux package like deb, rpm … or even zip files, also there is a set of tests like unit tests and integration tests. this phase is critical!

Test:

The build was succeeded, no it’s time to deploy the build artifacts to the staging server when we apply a set of manual and automated tests ( UAT ).

Release:

it’s the final step for the code work, so we make a release and announce a stable version of our code that is fully functional! also, we can tag it with a version number.

Deploy:

A pre-prod or a production server is the target now, to make our app up and running

Operate:

It’s all about infrastructure preparation and environment set up with some tools like terraform for IaaC, Ansible for configuration management, and security stuff configurations …

Monitor:

The performance is very important, so we install and configure some monitoring tools like ELK, Nagios, and datadog to get all information about the applications like CPU and memory usage …

Deploying an angular app

In this example, we will deploy a simple angular app on two environments.

• On VPS ( OVH provider) as a development server.
• on Heroku as a staging server.

So you must have a VPS and a Heroku account to continue with me.

The application repository is here : Github repo.

1. Clone the project with git clone https://github.com/hatembentayeb/angular-devops
2. run npm install && ng serve to run the app locally

Preparing the deployment for Heroku

Nginx is a popular and powerful web server that can be used to serve a large variety of apps based on python, angular, and react …

I will go through an optimization process to produce a clean and lightweight docker container with the best practices as much as I can.

Writing the Dockerfile

First, we will prepare the Dockerfile to be deployed to the Heroku cloud, so there are some tricks to make it work smoothly, make sure that you have an account and simply click new to create an app :

create a Heroku app

Make sure to give a valid name for your app, then go to your account settings and get your API_KEY that we will use in the pipeline file:

getting API key

let’s take a look at the dockerfile of the app:

This Dockerfile is split into two stages :

• Builder stage: The name of the stage is builder, it is a temporary docker container that produces an artifact which is the dist/ folder created by ng build --prod that compiles our project to produce a single HTML page and some *js & *.css. The base images that are used here are trion/ng-cli that contains all requirements to run an angular up and it’s accessible for public use in the Docker-hub, the public docker registry. Make sure to install all app requirement packages with npm ci, the ci command is used often in the continuous integration environments because it is faster than npm install.
• Final stage: The base image for this stage is nginx:1.17.5 and simply we copy the dist/ folder from the builder stage to the /var/share/nginx/html folder in the nginx container with the command COPY --from=builder ... There are additional configurations required to run the app, we need to configure nginx, there is a file named default.conf.template that contains a basic nginx configuration so we copy it to the container under /etc/nginx/conf.d/default.conf.template , this file has the $PORT variable that has to be changed when building the docker image in the Heroku environment. The default.conf.template :

server {                         
listen $PORT default_server;

location / {                           
include  /etc/nginx/mime.types;                                                      root   /usr/share/nginx/html/;
index  index.html index.htm;       
}                                                                       }</span>

Also, make sure to copy the nginx.conf under the /etc/nginx/nginx.conf, you are free to change and modify 😃, but for now I will use the default settings. The last command is a little bit confusing so let’s break it down :

CMD /bin/bash -c “envsubst ‘\$PORT’ < /etc/nginx/conf.d/default.conf.template > /etc/nginx/conf.d/default.conf” && nginx -g ‘daemon off;’</span>

→ /bin/bash -c ‘ command’: This command will run a Linux command with the bash shell. → envsubst: It is a program that substitutes the values of environment variables, so it will replace the $PORT from the Heroku environment and replace it in the default.conf.template file with its value, this variable is given by Heroku and attached to your app name, then we rename the template with default.conf which is recognized by nginx. → nginx -g ‘daemon off;’: The daemon off; directive tells Nginx to stay in the foreground. For containers, this is useful as the best practice is for one container = one process. One server (container) has only one service.

Preparing the deployment for the VPS on OVH

We will use the VPS as a development server so no need for a docker now we will use ssh for this after all make sure to have a VPS, ssh credentials, and a public IP.

I assume you have nginx installed, if not try to do it, it is simple 😙

In this tutorial I will be using the sshpass command, it is powerful and suitable for CI environments. You can install it with: apt-get install sshpass -y .

lets deploy the app to our server from the local machine, navigate to the repo and run ng build --prod , then navigate to dist/my-first-app folder and type this command :

sshpass  scp -v -p <password>  -o stricthostkeychecking=no -r *.* root@<vps-ip>:/usr/share/nginx/html</span>

If you don’t want to hardcode the password in the command line try to set the SSHPASS variable with your password like this export SSHPASS=" password" and replace -p with -e to use the environment variable.

Now all things are almost done! great 😃 ! let’s prepare the pipeline in the GitHub actions which is a fast and powerful ci system provided by GitHub inc.

Under the project root folder create the file main.yml in the github/wokflows folder, this directory is hidden so must start with a point like this: .github/workflows/main.yml

Preparing the pipeline

let’s take a look at the pipeline steps and configurations :

.github/workflows/main.yml

• Block 1: In this block, we define the workflow name and the actions that must be performed to start the build, test, and deployment. and of course, you have to specify the branch of your repo (by default master ).
• Block 2: The jobs keyword has to sub-keywords build and steps, the build define the base os for the continuous integration environment, in this case, we will use ubuntu-latest, also we define the node-version as a matrix that allows us to use multiple node versions in the list, in this case, we need only 12.x. The steps allow us to define the workflow steps and configurations ( build, test, deploy...).
• Block 3 : actions/checkout@v1 is used to clone the app code in the ci env. this action is provided by GitHub. Let's define a cache action with the name cache node modules, the name is up to you 😃, then we use a predefined action called actions/cache@v1 and specify the folders that we want to cache.
• Block 4: Installing and configuring the node run-time with an action called actions/node-setup@v1 and pass to it the desired node version that we already defined.
• Block 5: The show will begin now! let’s configure the build and the deployment to the VPS. Create two environment variables SSHPASS for the sshpass command and define the server address, make sure to define these values on the GitHub secrets under setting on the top of your repo files. Under the run keyword put your deployment logic. so we need the sshpass command and the angular cli to be installed, then install all required packages and build the app with the production mode --prod, next, navigate to the dist/my-first-app folder and run the sshpass command with a set of arguments to remove the older app in the server and deploy the new code.
• Block 6: Now Heroku is our target, so define also two env. variables, the Heroku registry URL and the API KEY to gain access to the registry using docker, next we need to define a special variable HEROKU_API_KEY that is used by Heroku cli, next, we login to the Heroku container and build the docker image then we pushed to the registry. we need to specify the target app in my case I named it angulardevops. After deploying the docker image we need to release it and tell the Heroku dynos to run our app on a Heroku server, using 1 server web=1, note that web is the name of the docker image that we already pushed.

We are almost done! now try to make a change in the app code and push it to GitHub, the workflow will start automatically 🎉 🎉 😄 !

You can view the app here: https://angulardevops.herokuapp.com/

Finally, this tutorial is aimed to help developers and DevOps engineers to deploy an Angular app, I hope it is helpful 😍. for any feedback please contact me!

If this post was helpful click the clap button as much as possible 😃.

Thank you 😃

Before we begin, I would like to thank Astrolab-Agency for the Internship opportunity and for their trust in me to make this project, I would like to thank Mr Mahdi Ben Chikh for his precious support along the intern period.

What is Rust ?

Rust is a programming language ( general purpose) C-like, which means it is a compiled language and it comes with new strong features in managing memory and more. The cool thing! rust does not have a garbage collector and that is awesome 😅 .

What is DevOps ?

In short, DevOps is the key feature that helps the dev team and the ops team to be friends 😃 without work conflicts, It is the ART of automation. It increases the velocity of delivering better software!

Identifying the problem

we can make a lot of things with rust like web apps, system drivers, and much more but there is one problem which is the time that rust takes to make a binary by downloading dependencies and compile them.

The cargo command helps us to download packages ( crates in the rust world), The Rustc is our compiler. Now we need to make a pipeline using the Gitlab CI/CD and docker to make the deployment faster.

This is our challenge and the Goal of this article! 👊

Static linking Vs Dynamic linking

Rust by default uses a Dynamic linking method to build the binary, so what is dynamic linking ?.

The Dynamic linking uses shared libraries, so the lib is loaded into the memory and only the address is integrated into the binary. In this case, the libc is used.

The Static linking uses static libraries that are integrated physically into the binary, no addresses are used and the binary size will be bigger. In this case, the musl libc is used.

You want to know more ? Then check this : click here.

Optimizing the CI/CD pipeline

The CI/CD pipeline is a set of steps that allow us to make :

build → test → deploy

In this article, I will focus on the build stage because in my opinion it is a very sensitive phase and it will affect the “Time to market” approach!

So the first thing is to optimize the size of our docker images to make the deployment faster. Before we begin, I will use a simple rust project for the demo.

The project structure

let’s understand the project structure :

• src : This dir contains all source code of the app (*.rs files).
• Cargo.toml: This file contains the package meta-data and the dependencies required by the app and some other features ….
• Cargo.lock : Ct contains the exact information about your dependencies.
• Rocket.toml: With this file, we specify the app status ( development, staging, or production) and the required configuration for each mode, for example, the port configuration for each environment.
• Dockerfile: This is the docker file configuration to build the image with the specific environment that is configured already in Rocket.toml.

Are you prepared 👊 😈 !!! , let’s begin the show !! 🎉 🎉 🎉

We will begin by building the app image locally, so let’s see how the docker file looks like :

This Dockerfile is split into two sections :

• The builder section ( a temporary container)
• The final image (Reduced in size)

The builder section:

In order to use rust, we have to get pre-configured images that contain the Rustc compiler and the Cargo tool. the image has the rust nightly build version and this is a real challenge because it’s not stable 😠.

We will use the static linking to get a fully functional binary that doesn’t need any shared libraries from the host image !!

let’s breakdown the code :

• First we import the base image.
• We need the MUSL support: musl-tool after updating the source.list of your packages apt-get update, MUSL is an easy-to-deploy static and minimal dynamically linked programs.
• Now we have to specify the target if you don’t know! no problem! you can use x86_64-unknown-Linux-musl, run with Rustup (the rust toolchain installer)
• To define the project structure on the container we use cargo new --bin material (material is the project name), it’s much like the structure that we see earlier.
• Making the material directory as a default we use the WORKDIR Dockerfile command.
• The Cargo.toml and Cargo.lock are required for deps. installation
• Setting up the RUST_FLAGS with -Clinker=musl-GCC: this flag tells cargo to use the musl GCC to compile the source code, the --release argument is used to prepare the code for a release ( final binary optimization).
• --target specify the target compilation 64 or 32 bit
• --feature vendored this command is an angle 😄 ! it helps to solve any SSL problem by finding the SSL resources automatically without specifying the SSL lib directory and the SSL include directory. It saves me a lot of time, this command is associated with some configurations in the Cargo.toml file under the feature section.

Until now we only build the dependencies in Cargo.toml and we make the clean ( removing unnecessary files)

• After downloading and compiling required packages, it’s time to get the source code into the container and make the final build to produce the final binary ( standalone).

The builder stage has complete! congrats 😙 🎉 yeah !!. Now let’s use alpine as a base image to get the binary from the build stage, but! wait for a second ! what is alpine ???

Alpine is a Linux distribution, it’s characterized in the docker world by its size! it is a very small image (4MB) and it contains only the base commands (busybox)

• --from=cargo-build ..../material now we will copy the final binary to the alpine and the intermediate container (cargo-build) will be destroyed and we get as a result a very tiny image (12–20MB) ready to use 😃 😃 😃

You know how to build a docker image right 😲 ? okay 😃

The CI/CD pipeline

After testing the image locally, it seems good 😃, we resolve the docker image size, but in the CI system the velocity is very important than size !! so let’s take this challenge and reduce the compilation time of this rust project !!

let’s look at the .gitlab-ci.yml file ( _our CI confi_guration):

There is a tip in this file, I just split the docker file into two stages in this .gitlab-ci.yml :

• The builder stage (rustdocker/rust..)→ build dependencies and binary
• The final stage (Alpine) → the build stage

For the CI work, I prepared a ready-to-use Docker image that contains all I need to make a reliable and fast pipeline for the rust project, this image is hosted in my docker hub .

hatembt/rust-ci:latest

This image contains the following packages installed and configured :

• The sccache command: this command caches the compiled dependencies! so by making this action to our build we can compile deps only one time !! 😅 , and we gained much more time.
• The cargo-audit: it’s a helpful command lets us to scan dependencies security.

Let’s breakdown the code and understand what’s going on !!

In the first job : _prepare_deps_forcargo we need our base image hatembt/rust-ci .

In this job some setting are required to make a successful build are placed in the before_script:

• Defining the cargo home in the path variable.
• Defining the cache directory that s generated by sccache (it contains the compilation cache ).
• Adding cargo and rustup ( tey are under .cargo/bin) in the path.
• Specifying the RUSTC_WRAPPER variable in order to use the sccache command with the rustc or MUSL in our case.

Now all thing are ready! so let’s make the build in the script section, you are already now what we should do 😃 , let’s skip it 👇.

The cache and artifacts sections are very important ! its saves the data under :

• .cargo/
• .cache/sccache
• target/x86_64-unknown-linux-musl/release/material (this is our final binary ).

To know more about caching and artifacts flow this link.

All data that is created in the first run of the CI jobs will be now saved and uploaded to the Gitlab coordinator. On the next build (new codes are pushed), we will not start the build from scratch, we just build the new packages, the old data will be injected with <<:*caching_rust after the image keyword.

let’s move on to the next JOB: build_docker_image:

I made a new Dockerfile for the docker build stage, it’s based on the alpine image and it contains only the binary from the previous stage.

The new Dockerfile:

First, we need a docker in docker image (dind) → to get the docker command and let’s take the steps below:

• login to the Gitlab registry
• Build the image with the new Dockerfile
• Push the image to Gitlab registry

and Now the results! 😧

The image size is :

image size

The CI Time:

NB: the time is for the whole build time, the built binary and docker_build stages

This is the power of DevOps, the art of automation with some philosophy in the configurations, and the steps to flow we can make even better than these results.

In business the velocity, the quality, and the necessary features (on the application) are very important to Bring the company to high levels of success → this is the successful Digital transformation.

Finally, I hope that this Story helps you to move on to the next steps in the CI/CD systems, you can apply these ideas into any language (mostly compiled languages, but still the same steps). If you have any feedback or critiques, please feel free to share them with me. If this walkthrough helped you, please like 👏 the article and connect with me on LinkedIn.

Thank you 😄

Hello to the second part of the “hello docker “ series, if your are new on docker please check the previous part by following this hello docker 😃 — Part I, In this lecture i will show you more advanced feature of the docker command line, also we will create a basic dockerized project for a simple python app with flask and we will push to dockerhub.

Common Docker commands

In this section I am going to show you the most used docker commands so let’s begin :

• To get info about your docker environment use : docker info
• To remove a container use : docker rm <name | ID>
• To remove an entire image use : docker rmi <name | ID>
• To remove a container after run use : docker run --rm <name|ID>
• To view current running containers use : docker ps
• To view all running and exited containers use: docker ps -a
• To view all and only the IDs of containers use : docker ps -a -q
• To get all images use : docker images
• To remove all images use : docker rm $(docker ps -a -q)
• To view the images use : docker images -f"dangling=true"
• To remove them use : docker rmi $(docker images -f"dangling=true" -q)
• To run the container in background use : docker run -d ... <name|ID>

That’s enough for now 😆, no lets build a simple python project with flask

The Flask app

Flask is a simple and powerful Framework for python like apache or tomcat... So let's begin :

The app.py file

from flask import Flask
app = Flask(__name__)

@app.route("/")
    def hello():
        return "Hello My Name is Hatem"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Make sure to install flask with pip install flask and run the script with python app.py and open your browser on localhost:8080/ .

Let’s generate the requirements.txt , we will not use pip freeze here (we are not in a virtual environment) but we will use pipreqs and make sure to install it with pip install pipreqs .

use pipreqs <path to the python project> to generate it.

Now let’s write the Dockerfile :

Dockerfile

FROM python:latest
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
CMD python app.py

• FROM python:latest : using python as a base image.
• WORKDIR /app : using /app as a default directory.
• COPY requirements.txt . compy this file to /app RUN pip install -r req..txt : install the required dependencies
• COPY app.py . : copy the app script to /app
• CMD python app.py : The container entry point when we run it
• Run the build process with docker build -t hello_flask .

Run the container docker rn --rm -p 8080: 8080 hello_flask , the -p 8080:8080 : will map the port 8080 on your host to the port 8080 in your container → this is the port mapping in docker, you can change the host port to any port you want and must be > 1024 ( ports < 1024 are reserved by the system).

Environment variables in Docker

An environment variable is a variable whose value is set outside the program, typically through the functionality built into the operating system or microservice. An environment variable is made up of a name/value pair, and any number may be created and available for reference at a point in time. → source for more information.

let’s use them in our example :

import os 
@app.route("/")
def hello():
    return "Hello My Name is {}".format(os.environ['NAME'])

the os.environ['NAME'] will fetch the NAME variable and get its value and return it in the browser. make sure to build the container again and run it like this : docker run --rm -p 8080:8080 -e "NAME=steve" hello_flask

Volumes with Docker

In order to be able to save (persist) data and also to share data between containers, Docker came up with the concept of volumes. Quite simply, volumes are directories (or files) that are outside of the default Union File System and exist as normal directories and files on the host filesystem.

→ source

let’s make some change to our script :

@app.route("/name_from_file")
def name_from_file():
    with open("files/name.txt","r") as file :
        name= file.readline()
    return "Hello My Name is {}".format(name)

Make sure to add a directory named “files” and add a file named “name.txt” that contains your name or whatever you want.

Now make the build again ! and run it with this command :

docker run --rm -v ${PWD}/files:/app/files -e "NAME=steve" -p 8080:8080 hello_flask

Now open your browser and type localhost:8080/name_from_file , you should see the name that you already add it in the name.txt file. In this case, you can change the content of the file in real-time and reload the page, you should see the changes 😆.

Saving and publishing images

After finalizing your work there are two things you should do :

• Saving images to tarballs or compressed archives
• Publishing images to registries to be used in public or private…

Let's begin by saving our example image to a tarball by running this command docker save --output hello_flask.tar hello_flask , now, check your current directory and type in the terminal ls -sh hello_flask.tar to get the archive size. if you want to reduce the archive size use the gzip command which is compression tools. Execute this command :

docker save hello_flask | gzip > hello_flask.tar.gz

and check the size again 😃. you can now upload them to your cloud storage or wherever you want. Now if you want to load the tar file to the docker engine simply run :

docker image load -i hello_flask.tar

Docker hub is our target now, to publish images in it you have to make an account first. the image name must be with this syntax account_name/image_name:image_tag so let's rename our image by running this command :

docker tag hello_flask hatembt/hello_flask:latest

Now you have to log in to your account and push the image to the public :

docker login 
docker push hatembt/hello_flask:latest

To pull the image just run docker pull hatembt/hello_flask:latest , no need for credentials here 😃 .

Finally, I hope that this tutorial is helpful to everyone who wants to know docker. In Part III, we will go through a complex project ( Front-end + Back-end + Database) and we will use docker-compose as an orchestrator. If you have any feedback please share it with me Hatem Ben Tayeb 😆.

Thank you 😃

In this story i will share my docker experience, so, be ready ! to know the most used container technologies in the hole world ! . I will help you to get started in docker also we will deep dive into cool features … , and by the end of this story you will be able to make your own projects using docker and docker-compose 😅. The second part is ready : hello docker part II

What is Docker ?

In a simple way … Docker is a way to bundle an app and it’s requirements into a single Image that can be runnable in any environment like Windows, Linux, Mac os and of course the cloud.

A docker Image is a micro os like ubuntu, debian and archlinux …, But what is a micro os ? simply it’s a very tiny os that contains only a file system and some basic command and of course a package manager like apt and pacman …

What i need to get started ?

I am not going through the installation process or explaining the functional part of docker … i will go through examples from real life and some cool tips and tricks .

• Docker installation : Clik here
• Docker vs virtual machine : Click here

You must READ them 😠

Check your docker status by running this command :

$ sudo systemctl status docker

If docker is not running make sure to run this command

$ sudo systemctl start docker

Running your first container

After installing docker, now you are able to follow this article, so … let’s run our first container by running this command and i will explain every step 😃

$ docker run hello-world

This is the output :

By this command we tell the docker engine to run an image called “hello-world”, which is an image that contains a simple script with the output that begins with “ Hello from docker …” so … what happens here ?

The docker engine searches for this image in the local registry but he tells us that he didn’t find it so it goes to a global registry which is a huge and public place for free images (created by other peoples ) called docker hub.

He pull or download the image then he run it, and finally we get the message or the execution result of the script inside the image. To download only the image we use ’’docker pull hello-world’’.

Let’s try another one , in this case i have an ARCHLINUX based os and i want to run an alpine system with docker and make some work on it so let’s go 😄

docker pull alpine:latest

docker run -it alpine sh

Output :

We have downloaded the alpine image and we run it interactively by adding “ -it” and “sh” at the end :

• -i : for the interactive mode with -t option ( we can give input and type some commands to interact with the alpine system)
• -t : Allocate a pseudo-TTY (PTY) to emulate a hardware terminal we used often with ssh and telnet protocols .
• sh : is the default shell ( like bash, csh and zsh …)

The other commands ( ls , cat …) are a basic commands that are founded on any other Linux systems.

Commit a docker container

What is the difference between a docker image and a container ? Simply the docker image is the basic resource and it can be shared by multiple containers but how ? when we make a “docker run” , the docker engine make a snapshot or a copy of the base image in the memory and we use it like we did with alpine ,after some work on the snapshot or the container we usually stop and exit the container, and every container is identified with a unique hash (ID),

To add the changes that we make on the snapshot to the base image we use the “commit” command to persist our changes so let’s try out :

Watch this demo :

docker commit

We have created a new image named “_alpinemodified” that contains a “hello.sh” fileunder the “/home” folder . You surely notice that the original modification in the alpine image is gone now.

Create your own image

Another way to save changes or create some stuff in containers is the “Dockerfile” , which is a a set of instructions that define the final state of your image .

This file uses YAML syntax which is easy to understand and so clean 😄, so let’s go writing our first Dockerfile :

dockerfile

In this file we have two keywords :

• FROM : this is the base image that we use .
• CMD : the Command keyword , this command will run the “echo hello” when we use the “docker run “.

let’s build the image :

$ docker build -t hello .

• build : will make the build process by executing every instruction (step)
• -t : giving a name to our image
• . : our build context which we have the “Dockerfile”, or you can specify the hole path.

note: don’t forget the dot “.” please !!

Watch the demo :

hello_alpine

To get all images try to run : docker images , if you want to get more information about your image run this command : docker inspect hello and try to figure out what happens here , i will cover this topic in the next stories … .

Finally, this tutorial is just an introduction to docker for beginners, in the next parts i will talk about more advanced features in docker. If you have feedback feel free to share them with me Hatem Ben Tayeb.

If this post was helpful click the clap button as much as possible 😃. The second part is ready : Learn Docker From Scratch

Thank you 😃

Producing documentation may be painful and need a lot of time to write and operate. In this story, I will share with you, my way of generating docs using the DevOps approach. To make life easier, we will explore the art of automation 😃.

Let’s go folks 😙

Create a Gitlab repo

This is straightforward, follow these steps:

• Log in to your GitLab
• Click new project
• Give it a name: auto_docs
• Initialize it with a README.md file
• Make it public or private
• Hit create

Now clone the project by copying the URL and run this command :

$ git clone [https://gitlab.com/auto_docs.git](https://gitlab.com/auto_docs.git)</span>

Setting up the environment

I’m using a Linux environment but it is possible to reproduce the same steps on a Windows machine.

In order to follow me, you need a set of tools that must be available on your machine … make sure to have python3 installed, I have python 3.8 (latest).

Creating a virtual environment

The easiest way to set up a virtual environment is to install virtualenv python package by executing pip install virtualenv .

Navigate to your local GitLab repository and create a new virtual environment.

$ cd auto_docs/
$ virtualenv autodocs
$ source autodocs/bin/acivate</span>

Installing Mkdocs Material

Make sure that the virtual environment is active.

Install the mkdocs material with this command: pip install mkdocs-material. This package needs some dependencies to work .. install them by using a requirement.txt file, copy-paste the dependencies list to filename requirements.txt

Babel==2.8.0
click==7.1.1
future==0.18.2
gitdb==4.0.4
GitPython==3.1.1
htmlmin==0.1.12
Jinja2==2.11.2
joblib==0.14.1
jsmin==2.2.2
livereload==2.6.1
lunr==0.5.6
Markdown==3.2.1
MarkupSafe==1.1.1
mkdocs==1.1
mkdocs-awesome-pages-plugin==2.2.1
mkdocs-git-revision-date-localized-plugin==0.5.0
mkdocs-material==5.1.1
mkdocs-material-extensions==1.0b1
mkdocs-minify-plugin==0.3.0
nltk==3.5
Pygments==2.6.1
pymdown-extensions==7.0
pytz==2019.3
PyYAML==5.3.1
regex==2020.4.4
six==1.14.0
smmap==3.0.2
tornado==6.0.4
tqdm==4.45.0</span>

Install them all with one command: pip install -r requirements.txt Now it’s time to create a new mkdocs project 😅.

Run this command : mkdocs new . and verify that you have this structure :

|--auto_docs
    |--- docs
    |--- mkdocs.yml</span>

• The docs folder contains the structure of your documentation, it contains subfolders and markdown files.
• The mkdocs.yml file defines the configuration of the generated site.

Let's test the installation by running this command: mkdocs serve. The site will be accessible on http://locahost:8000 and you should see the initial look of the docs.

Setting up the CI/CD

let’s enable le CI/CD to automate the build and the deployment of the docs. Notice that GitLab offers a feature called GitLab pages that can serve for free a static resource (HTML, js, CSS). The repo path is converted to an URL to your docs.

Create the CI/CD file

Gitlab uses a YAML file — it holds the pipeline configuration.

The CI file content:

stages :
  - build</span><span id="3031" class="fu lb ji ex kt b lc mb mc md me mf le s lf">pages:
  stage: build
  image:
  name: squidfunk/mkdocs-material
  entrypoint:
    - ""
  script:
    - mkdocs build
    - mv site public
  artifacts:
    paths:
      - public
  only:
    - master
  tags:
    - gitlab-org-docker</span>

This pipeline uses a docker executor with an image that contains mkdocs already installed… mkdocs build the project and put the build assets on a folder called site … to be able to use GitLab pages you have to name your job pages and put the site assets into a new folder called public.

For tags: check the runner's section under settings → CI/CD →Runners and pick one of the shared runners that have a tag GitLab-org-docker.

All things were done 🎉 🎉 😸 !

Oh! just one thing … we forgot the virtual environment files .. they are big and not needed on the pipeline … they are for the local development only. The mkdocs image on the pipeline is already shipped with the necessary packages.

So … create a new file called .gitignore and add these lines:

auto_docs/ 
requirements.txt</span>

The auto_docs folder has the same name as the virtual environment .. don't forget 😠! you will be punished by pushing +100Mi 😝 and you will wait your whole life to complete the process haha 😢.

Now run git add. && git commit -m "initial commit" a && git push … go to your GitLab repo and click CI/CD → pipelines, click on the blue icon and visualize the logs .. once the job succeeded, navigate to settings -> pages and click the link of your new documentation site (you have to wait for 10m~ to be accessible)

Finally, I hope this was helpful! thanks for reading 😺 😍!

In this Post we will setup a React pipeline using Gitlab,Ansible and docker. we will go throught the whole process from nothing to a fast, reliable and hightly customizable pipeline with multi-environment deployment.

Daah ! let's start i can't wait !

Tools

Before we start we need to define the damn tech stack :

1. Gitlab : GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager providing wiki, issue-tracking and continuous integration and deployment pipeline features.

2. Ansible : Ansible is the simplest way to automate apps and IT infrastructure. Application Deployment + Configuration Management + Continuous Delivery.

3. Docker: Docker is a tool designed to make it easier to create, deploy, and run applications by using containers.

Note: if you dont know nothing about those tools ... No problem .... aaah actually it's a problem ... we are diving into advanced topic here ...

Come on ! i was kidding

Actually no ...
contact me if you need some support

Architecture

yoo .. we have to draw the global environment architecture to get the whole picture about what we will do here ... dont start coding directly. Daaah ... you have to think by compiling the whole process in mind

Of course we will create a repository ( i will not explain that ) on gitlab with a hello world react app ( i will not explain that ) and push it there.

Let's break down the architecture now :

• Block 1 : this where our code application resides and the whole gitlab eco-system also, all configuration to start a pipeline must be there, actually you can install gitlab on your own servers .. but it's not the aim of this post.

• Block 2: this is the important block for now (The CI environment) .. actually it is the server when all the dirty work resides like buiding docker containers .. saving cache ... testing code and so on ... we must configure this environment with love haha yeah with love ... it's is the base of the pipeline speed and low level configurations.

• Block 3 : the target environments where we will deploy our application using ansible playbooks via a secure tunnel .. SSH ... BTW i love you SSH because we will not install any runners on those targets servers we will interact with them only with ansible to ensure a clean deployment.

CI environment

In this section we will connect our gitlab repo to the CI environment machine and install the gitlab runner on it of course.

1. Go to your repo ... under settings --> CI/CD --> runners and get the gitlab url and the token associeted to ... dont loose it :expressionless:

2. You should have a VPS or a virtual machine on the cloud ... i will work on an azure virtual machine with ubuntu 18.04 installed

3. Install docker of course ... it's simple come here
4. Installing the gitlab runner :

curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_<arch>.deb"

dpkg -i gitlab-runner_<arch>.deb

Gitlab will be installed as service on your machine but i don't you can encounter a problem when starting it ... (don't ask me i don't know ) so you can start it as follow :

gitlab runner run & # it will work on background

You can now register the runner with gitlab-runner register and follow the instructions ... dont loose the token or reset it ... if you reset the token you have to re-register the runner again. i will make things easier ... here is my config.toml under /etc/gitlab-runner/config.toml

concurrent = 9 
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "runner-name"
  url = "https://gitlab.com/"
  token = "runner-token"
  executor = "docker"
  limit = 0
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    pull_policy = "if-not-present"
    tls_verify = false
    image = "alpine"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache:/cache"]
    shm_size = 0

let's make a breakdown here ...

This runner will run 9 concurent jobs on a docker containers (docker in docker) based on the alpine container (to make a clean build) ... The runner will pull new versions of images if they are not present ... This is optional you can turn it to always but we need to speed up the build ... No need to pull the same image again and again if there is no updates ... The runner will save the cache on the current machine under /cache on the host and pass it in use as a docker volume to save some minutes when gitlab by default upload the zipped cache to it's own storage and download it again ... It's painfull when the cache is becoming huge. At some point on time the cache will be so big .. So you can make your hand dirty and delete the shit

We are almost done !

Now you can go the repository under settings --> CI/CD --> runners and verify that the runner was registred successfully ( the green icon )

. . .

The react pipeline

let's code the pipeline now .... wait a second !!! we need the architecture as the previous section ... so here is how the pipeline will look like ...

This pipeline aims to support the folowing features :

• Caching node modules for faster build
• Docker for shiping containers
• Gitlab private registry linked to the repo
• Ship only /build on the container with nginx web server
• Tag containers with the git SHA-COMMIT
• Deploy containers with an ansible playbook
• SSH configuration as a gitlab secret to secure the target IP
• Only ssh keypairs used for authentication with the target server ... no damn passwords ...

. . .

Defining Secrets

This pipeline needs some variables to be placed in gitlab as secrets on settings --> CI/CD --> Variables :

The SSH_CFG looks like this :

Host *
   StrictHostKeyChecking no

Host dev 
    HostName <IP>
    IdentityFile ./keys/keyfile
    User root

Host staging 
    HostName <IP>
    IdentityFile ./keys/keyfile
    User root

Host prod 
    HostName <IP>
    IdentityFile ./keys/keyfile
    User root

I will not explain this ... come here

. . .

KNOCK KNOCK ... are you still here

. . .

Preparing Dockerfile

Before writing the dockerfile take in mind that the steup should be compatible with the pipeline architecture ... if you remember we have a separate jobs for :

• Installing node modules
• Run the build process

So the Dockerfile must contain only the builded assets only to be served by nginx

Here is our sweet Dockerfile :

FROM nginx:1.16.0-alpine
COPY build/  /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d
RUN mv  /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.old
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

This dockerfile does not do too much work, it just take the /build directory and copy it under /usr/share/nginx/html to be served.

Also we need a basic nginx config like follow to be under /etc/nginx/conf.d:

server {
  include mime.types;
  listen 80;
  location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
    try_files $uri $uri/ /index.html;
  }
  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
    root   /usr/share/nginx/html;
  }
}

You see ! its simple let's proceed to setup the ansible playbook for the deployment process ... hurry up

. . .

Deployment with ansible

We are almost done ! the task now is to write the ansible playbook that will do the folowing :

• Create a docker network and specify the the gateway address
• Authenticate the gitlab registry
• Start the container with the suitable configurations
• Clean the unsed containers and volumes
• Most setup will be in the inventory file

Let's take a look at the inventory_file:

[dev]
devserver ansible_ssh_host=dev ansible_ssh_user=root ansible_python_interpreter=/usr/bin/python

[dev:vars]
c_name={{ lookup('env','CI_PROJECT_NAME') }}-dev #container name
h_name={{ lookup('env','CI_PROJECT_NAME') }}-dev #host name
subnet=172.30.0  # network gateway                                         
network_name=project_name_dev
registry_url={{ lookup('env','CI_REGISTRY') }}                          
registry_user={{ lookup('env','GITLAB_REGISTRY_USER') }}    
registry_password={{ lookup('env','GITLAB_REGISTRY_PASS') }}  
image_name={{ lookup('env','CI_REGISTRY_IMAGE') }}:{{ lookup('env','CI_COMMIT_SHORT_SHA') }}-dev 

[project_network:children]
dev
[project_clean:children]
dev

The ansible_ssh_host=dev refers to the SSH_CFG configuration.

Gitlab by default exports many useful environment variables like :

• CI_PROJECT_NAME : the repo name
• CI_COMMIT_SHORT_SHA : the sha commit ID to tag the container

You can explore all variables here.

Let's move now to the playbook ... i'm tired damn it haha .. it is a long post ... okay nevermind come on ..

Here is the ansible playbook :

---
- hosts: project_network
  #become: yes # for previlged user
  #become_method: sudo   # for previlged user
  tasks:                                                     
  - name: Create docker network
    docker_network:
      name: "{{ network_name }}"
      ipam_config:
        - subnet: "{{ subnet }}.0/16"
          gateway: "{{ subnet }}.1"

- hosts: dev
  gather_facts: no
  #become: yes # for previlged user
  #become_method: sudo   # for previlged user
  tasks:

  - name: Log into gitlab registry and force re-authorization
    docker_login:
      registry: "{{ registry_url }}"
      username: "{{ registry_user }}"
      password: "{{ registry_password }}"
      reauthorize: yes

  - name : start the container
    docker_container:
      name: "{{ c_name }}"
      image : "{{ image_name }}"
      pull: yes
      restart_policy: always
      hostname: "{{ h_name }}"
      # volumes:
      #   - /some/path:/some/path
      exposed_ports:
        - "80"
      networks:
        - name: "{{ network_name }}"
          ipv4_address: "{{ subnet }}.2"
      purge_networks: yes

- hosts : project_clean
  #become: yes # for previlged user
  #become_method: sudo   # for previlged user
  gather_facts : no 
  tasks: 

  - name: Removing exited containers
    shell: docker ps -a -q -f status=exited | xargs --no-run-if-empty docker rm --volumes
  - name: Removing untagged images
    shell: docker images | awk '/^<none>/ { print $3 }' | xargs --no-run-if-empty docker rmi -f
  - name: Removing volume directories
    shell: docker volume ls -q --filter="dangling=true" | xargs --no-run-if-empty docker volume rm

This playbook is a life saver because we configure the container automatically before starting it ... no setup on the remote host ... we can deploy the same in any other servers based on linux. the container update is quite simple .. ansible will take care of stopping the container and starting new one with different tag and then clean up the shit

We can also make a rollback to the previous container by going to the previous pipeline history on gitlab and restart the lastest job the deploy job because we have already an existing container on the registry

The setup is for dev environment you can copy paste the two files for the prod & staging environment ...

. . .

Setting up the Pipeline

The pipeline will deploy to the three environments as i mentioned on the top of this post ...

Here is the full pipeline code :

variables: 
  DOCKER_IMAGE_PRODUCTION : $CI_REGISTRY_IMAGE 
  DOCKER_IMAGE_TEST : $CI_REGISTRY_IMAGE   
  DOCKER_IMAGE_DEV : $CI_REGISTRY_IMAGE


#caching node_modules folder for later use  
.example_cache: &example_cache
  cache:
    paths:
      - node_modules/


stages :
  - prep
  - build_dev
  - push_registry_dev
  - deploy_dev
  - build_test
  - push_registry_test
  - deploy_test
  - build_production
  - push_registry_production
  - deploy_production


########################################################
##                                                                                                                                 ##
##     Development: autorun after a push/merge                                               ## 
##                                                                                                                                 ##
########################################################

install_dependencies:
  image: node:12.2.0-alpine
  stage: prep
  <<: *example_cache
  script:
    - npm ci --log-level=error 

  artifacts:
    paths:
      - node_modules/  
  tags :
    -  runner_name 
  only:
    refs:
      - prod_branch
      - staging_branch
      - dev_branch
    changes :
      - "*.json"

build_react_dev:
  image: node:12.2.0-alpine
  stage: build_dev
  <<: *example_cache
  variables:
    CI : "false"
  script:
    - cat .env.dev > .env
    - npm run build

  artifacts:
    paths:
      - build/
  tags :
    -  runner_name 
  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "dev_branch"'


build_image_dev:
  stage: push_registry_dev
  image : docker:19
  services:
    - docker:19-dind
  variables: 
    DOCKER_HOST: tcp://docker:2375/
    DOCKER_DRIVER: overlay2
    DOCKER_TLS_CERTDIR: ""
  before_script:
  # docker login asks for the password to be passed through stdin for security
  # we use $CI_JOB_TOKEN here which is a special token provided by GitLab
    - echo -n $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY
  script:
    - docker build  --tag $DOCKER_IMAGE_DEV:$CI_COMMIT_SHORT_SHA-dev .
    - docker push $DOCKER_IMAGE_DEV:$CI_COMMIT_SHORT_SHA-dev
  tags :
    - runner_name
  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "dev_branch"'


deploy_dev:
  stage: deploy_dev
  image: willhallonline/ansible:latest
  script:
    - cat ${SSH_CFG} > "$CI_PROJECT_DIR/ssh.cfg"               
    - mkdir -p "$CI_PROJECT_DIR/keys"                            
    - cat ${ANSIBLE_KEY} > "$CI_PROJECT_DIR/keys/keyfile"      
    - chmod og-rwx "$CI_PROJECT_DIR/keys/keyfile"    
    - cd $CI_PROJECT_DIR && ansible-playbook  -i deployment/inventory_dev --ssh-extra-args="-F $CI_PROJECT_DIR/ssh.cfg -o ControlMaster=auto -o ControlPersist=30m" deployment/deploy_container_dev.yml
  after_script:
    - rm -r "$CI_PROJECT_DIR/keys" || true                              
    - rm "$CI_PROJECT_DIR/ssh.cfg" || true

  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "branch_dev"'
  tags :
    - runner_name

########################################################
##                                                                                                                                 ##
##     pre-production: autorun after a push/merge                                            ## 
##                                                                                                                                 ##
########################################################

build_react_test:
  image: node:12.2.0-alpine
  stage: build_test
  <<: *example_cache
  variables:
    CI : "false"
  script:
    - cat .env.test > .env
    - npm run build

  artifacts:
    paths:
      - build/
  tags :
    -  runner_name 

  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "staging_branch"'


build_image_test:
  stage: push_registry_test
  image : docker:19
  services:
    - docker:19-dind
  variables: 
    DOCKER_HOST: tcp://docker:2375/
    DOCKER_DRIVER: overlay2
    DOCKER_TLS_CERTDIR: ""
  before_script:
  # docker login asks for the password to be passed through stdin for security
  # we use $CI_JOB_TOKEN here which is a special token provided by GitLab
    - echo -n $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY
  script:
    - docker build  --tag $DOCKER_IMAGE_TEST:$CI_COMMIT_SHORT_SHA-test .
    - docker push $DOCKER_IMAGE_TEST:$CI_COMMIT_SHORT_SHA-test

  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger" && $CI_COMMIT_BRANCH == "staging_branch"'
  tags :
    - runner_name



deploy_test:
  stage: deploy_test
  image: willhallonline/ansible:latest
  script:
    - cat ${SSH_CFG} > "$CI_PROJECT_DIR/ssh.cfg"               
    - mkdir -p "$CI_PROJECT_DIR/keys"                            
    - cat ${ANSIBLE_KEY} > "$CI_PROJECT_DIR/keys/keyfile"      
    - chmod og-rwx "$CI_PROJECT_DIR/keys/keyfile"    
    - cd $CI_PROJECT_DIR && ansible-playbook  -i deployment/inventory_test --ssh-extra-args="-F $CI_PROJECT_DIR/ssh.cfg -o ControlMaster=auto -o ControlPersist=30m" deployment/deploy_container_test.yml
  after_script:
    - rm -r "$CI_PROJECT_DIR/keys" || true                              
    - rm "$CI_PROJECT_DIR/ssh.cfg" || true
  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger" && $CI_COMMIT_BRANCH == "staging_branch"'
  tags :
    - runner_name

########################################################
##                                                                                                                                 ##
##     Production: must be deployed manually                                                    ## 
##                                                                                                                                 ##
########################################################

build_react_production:
  image: node:12.2.0-alpine
  stage: build_production
  <<: *example_cache
  variables:
    CI : "false"
  script:
    - cat .env.prod > .env
    - npm run build

  artifacts:
    paths:
      - build/
  tags :
    -  runner_name 
  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "prod_branch"'
      when: manual

build_image_production:
  stage: push_registry_production
  image : docker:19
  services:
    - docker:19-dind
  variables: 
    DOCKER_HOST: tcp://docker:2375/
    DOCKER_DRIVER: overlay2
    DOCKER_TLS_CERTDIR: ""
  before_script:
  # docker login asks for the password to be passed through stdin for security
  # we use $CI_JOB_TOKEN here which is a special token provided by GitLab
    - echo -n $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY
  script:
    - docker build  --tag $DOCKER_IMAGE_PRODUCTION:$CI_COMMIT_SHORT_SHA .
    - docker push $DOCKER_IMAGE_PRODUCTION:$CI_COMMIT_SHORT_SHA

  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "prod_branch"'
  tags :
    - runner_name
  needs: [build_react_production]



deploy_production:
  stage: deploy_production
  image: willhallonline/ansible:latest
  script:
    - cat ${SSH_CFG} > "$CI_PROJECT_DIR/ssh.cfg"               
    - mkdir -p "$CI_PROJECT_DIR/keys"                            
    - cat ${ANSIBLE_KEY} > "$CI_PROJECT_DIR/keys/keyfile"      
    - chmod og-rwx "$CI_PROJECT_DIR/keys/keyfile"    
    - cd $CI_PROJECT_DIR && ansible-playbook  -i deployment/inventory --ssh-extra-args="-F $CI_PROJECT_DIR/ssh.cfg -o ControlMaster=auto -o ControlPersist=30m" deployment/deploy_container.yml
  after_script:
    - rm -r "$CI_PROJECT_DIR/keys" || true                              
    - rm "$CI_PROJECT_DIR/ssh.cfg" || true
  rules:
    - if: '$CI_PIPELINE_SOURCE != "trigger"  && $CI_COMMIT_BRANCH == "prod_branch"'
  tags :
    - runner_name
  needs: [build_image_production]

Here is some notes about this pipeline:

• The pipeline is protected by default to not be started with the trigger token ( Gitlab pipeline trigger)

• The prep stage will start if there is any modifications in any json file including the package.json file

• The pipeline jobs runs on docker alpine image (DinD) so we need some variables to connect to the docker host by using DOCKER_HOST: tcp://docker:2375/ and DOCKER_TLS_CERTDIR: ""

• The production deployment depends on the staging jobs to be succeeded and tested by the testing team. by default no auto deploy to prod ... it's manual !

• I used some files to store application environment variables using .env.dev , env.test and .env.prod you can use what you want !

• Make sure to use a good docker image for the job based images .. for node i always work with LTS versions.

• Create a deployment folder to store the ansible playbooks and inventory files.

• Create a Cron Job to delete the cache every three months to clean the cache on the CI environment.

• On the target server make sure to install docker, nginx, certbot and docker python package

  . . .

Final thoughts

You can make this pipeline as template to deliver other kinds of projects like :

• Python
• Rust
• Node
• Go

I hope this post was helpful ! thanks for reading it was great to share this with you, if you have any problems in setting this just let me know !

Thanks !