April 22, 2019

Qu'est-ce que l'approche CI/CD ?

L'approche CI/CD permet d'augmenter la fréquence de distribution des applications grâce à l'introduction de l'automatisation au niveau des étapes de développement des applications. Les principaux concepts liés à l'approche CI/CD sont l'intégration continue, la distribution continue et le déploiement continu. L'approche CI/CD représente une solution aux problèmes posés par l'intégration de nouveaux segments de code pour les équipes de développement et d'exploitation (ce qu'on appelle en anglais « integration hell », ou l'enfer de l'intégration).
Plus précisément, l'approche CI/CD garantit une automatisation et une surveillance continues tout au long du cycle de vie des applications, des phases d'intégration et de test jusqu'à la distribution et au déploiement. Ensemble, ces pratiques sont souvent désignées par l'expression « pipeline CI/CD » et elles reposent sur une collaboration agile entre les équipes de développement et d'exploitation.

Quelle est la différence entre CI et CD (et l'autre CD) ?

L'acronyme « CI/CD » a plusieurs significations. Le « CI » de CI/CD désigne toujours l'« intégration continue », à savoir un processus d'automatisation pour les développeurs. L'intégration continue consiste, pour les développeurs, à apporter régulièrement des modifications au code de leur application, à les tester, puis à les fusionner dans un référentiel partagé. Cette solution permet d'éviter de travailler en même temps sur un trop grand nombre d'éléments d'une application, qui pourraient entrer en conflit les uns avec les autres.
Le « CD » de CI/CD désigne la « distribution continue » et/ou le « déploiement continu », qui sont des concepts très proches, parfois utilisés de façon interchangeable. Les deux concepts concernent l'automatisation d'étapes plus avancées du pipeline, mais ils sont parfois dissociés pour illustrer le haut degré d'automatisation.
Dans le cadre de la distribution continue, généralement les modifications apportées par le développeur à une application sont automatiquement testées et téléchargées dans un référentiel (tel que GitHub ou un registre de conteneurs), où elles peuvent être déployées dans un environnement de production actif par l'équipe d'exploitation. Le processus de distribution continue permet de résoudre les problèmes de visibilité et de communication entre l'équipe de développement et l'équipe métier. Ainsi, son objectif consiste à simplifier au maximum le déploiement de nouveau code.
Le déploiement continu (l'autre signification possible de « CD ») peut désigner le transfert automatique des modifications du développeur depuis le référentiel vers l'environnement de production, où elles peuvent être utilisées par les clients. Ce processus permet de soulager les équipes d'exploitation surchargées par les tâches manuelles qui ralentissent la distribution des applications. Il repose sur la distribution continue et automatise l'étape suivante du pipeline.
L'expression « CI/CD » peut désigner soit uniquement les deux pratiques liées d'intégration continue et de distribution continue, soit les trois pratiques, c'est-à-dire l'intégration continue, la distribution continue et le déploiement continu. Pour compliquer encore les choses, il arrive que l'expression « distribution continue » englobe également le processus de déploiement continu.
En conclusion, mieux vaut ne pas trop s'attarder sur ces questions de sémantique. Il suffit de retenir que l'approche CI/CD se rapporte à un processus, souvent représenté sous forme de pipeline, qui consiste à introduire un haut degré d'automatisation et de surveillance continues dans le processus de développement des applications. La signification réelle de ces termes varie au cas par cas, selon le niveau d'automatisation du pipeline CI/CD. De nombreuses entreprises commencent par l'intégration continue, puis se mettent peu à peu à automatiser la distribution et le déploiement, par exemple dans le cadre du développement d'applications natives pour le cloud.

Intégration continue

Le concept de développement d'applications modernes consiste à faire travailler plusieurs développeurs simultanément sur différentes fonctions d'une même application. Toutefois, si une entreprise prévoit de fusionner tous ces morceaux de code source le même jour (le « merge day » ou « jour du fusionnement »), alors la tâche risque de s'avérer laborieuse et de nécessiter beaucoup de procédures manuelles et de temps. En effet, lorsqu'un développeur qui travaille seul apporte des modifications à une application, celles-ci peuvent entrer en conflit avec les différentes modifications apportées simultanément par d'autres développeurs.
L'intégration continue (CI) permet aux développeurs de fusionner plus fréquemment leurs modifications de code dans une « branche » partagée, ou un « tronc », parfois même tous les jours. Une fois que les modifications apportées par un développeur sont fusionnées, elles sont validées par la création automatique de l'application et l'exécution de différents niveaux de test automatisés (généralement des tests unitaires et d'intégration) qui permettent de vérifier que les modifications n'entraînent pas de dysfonctionnement au sein de l'application. En d'autres termes, il s'agit de tester absolument tout, des classes et fonctions jusqu'aux différents modules qui constituent l'application. En cas de détection d'un conflit entre le code existant et le nouveau code, le processus d'intégration continue permet de résoudre les dysfonctionnements plus facilement, plus rapidement et plus fréquemment.

Distribution continue

Après l'automatisation de la création et des tests unitaires et d'intégration dans le cadre de l'intégration continue, la distribution continue automatise la publication du code validé dans un référentiel. Aussi, pour garantir l'efficacité du processus de distribution continue, il faut d'abord introduire le processus d'intégration continue dans le pipeline de développement. La distribution continue permet de disposer d'une base de code toujours prête à être déployée dans un environnement de production.
Dans le cadre de la distribution continue, chaque étape (de la fusion des modifications de code jusqu'à la distribution des versions prêtes pour la production) implique l'automatisation des processus de test et de publication du code. À la fin de ce processus, l'équipe d'exploitation est en mesure de déployer facilement et rapidement une application dans un environnement de production.

Déploiement continu

L'étape finale d'un pipeline CI/CD mature est le déploiement continu. En complément du processus de distribution continue, qui automatise la publication d'une version prête pour la production dans un référentiel de code, le déploiement continu automatise le lancement d'une application dans un environnement de production. En l'absence de passerelle manuelle entre la production et l'étape précédente du pipeline, le déploiement continu dépend surtout de la conception de l'automatisation des processus de test.
Dans la pratique, dans le cadre du déploiement continu, une modification apportée par un développeur à une application pourrait être publiée quelques minutes seulement après la rédaction du code en question (en supposant qu'elle passe les tests automatisés). Il est ainsi beaucoup plus facile de recevoir et d'intégrer en continu les commentaires des utilisateurs. Ensemble, ces trois pratiques CI/CD réduisent les risques liés au déploiement des applications, puisqu'il est plus simple de publier des modifications par petites touches qu'en un seul bloc. Cette approche nécessite néanmoins un investissement de départ considérable, car les tests automatisés devront être rédigés de manière à s'adapter à un large éventail d'étapes de test et de lancement dans le pipeline CI/CD.


April 7, 2019

Installing Docker

In this lesson, we'll install the latest version of Docker CE. The commands used throughtout this video are below.

Prerequisites

Uninstall old versions:
sudo yum remove -y docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-engine

Install Docker CE

Add the Utilities needed for Docker:
sudo yum install -y yum-utils \
  device-mapper-persistent-data \
  lvm2
Set up the stable repository:
sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
Install Docker CE:
sudo yum -y install docker-ce
Enable and start Docker:
sudo systemctl start docker && sudo systemctl enable docker
Add cloud_user to the docker group:
sudo usermod -aG docker cloud_user

Source - Linux Academy

Magnum - OpenStack

Magnum is an OpenStack API service developed by the OpenStack Containers Team making container orchestration engines such as Docker Swarm, Kubernetes, and Apache Mesos available as first class resources in OpenStack. Magnum uses Heat to orchestrate an OS image which contains Docker and Kubernetes and runs that image in either virtual machines or bare metal in a cluster configuration. Click below for a ~2 minute demo of how the Magnum CLI works.
Demo-Preview-Frame.png

Getting Started / Download

To get started with Magnum, see: Our Quickstart Guide
Downloads:

Contributing

The project is under active development by our OpenStack Containers Team. We meet weekly by IRC.

Architecture

Magnum Architeture Diagram
Cluster Create/Update/Delete

Resources

IRC and IRC Meetings

Our developers use IRC in #openstack-containers on freenode for development discussion.

Users

  • CERN - details on the blog
  • (your group or organization here)

Frequently Asked Questions

1) How is Magnum is different from Nova?
Magnum provides a purpose built API to manage application containers orchestration engines, which have a distinctly different life cycle and operations than Nova (machine) Instances. We actually use Nova instances to compose our Clusters.
2) How is Magnum different than Docker or Kubernetes?
Magnum offers an asynchronous API that's compatible with Keystone, and a complete multi-tenancy implementation. It does not perform orchestration internally, and instead relies on OpenStack Orchestration. Magnum does leverage both Kubernetes and Docker as components.
3) Is this the same thing as Nova-Docker?
No, Nova-Docker is a virt driver for Nova that allows containers to be created as Nova instances. This is suitable for use cases when you want to treat a container like a lightweight machine. Magnum provides container orchestration engine management that is beyond the scope of Nova's API, and implements its own API to surface these features in a way that is consistent with other OpenStack services. Containers started on Magnum Clusters are run on top of Nova instances that are created using Heat.
4) Who is Magnum for?
Magnum is for OpenStack cloud operators (public or private) who want to offer a self-service solution to provide a hosted containers service to their cloud users. Magnum simplifies the required integration with OpenStack, and allows for cloud users who can already launch cloud resources such as Nova Instances, Cinder Volumes, Trove Databases, etc. to also create container clusters (Clusters) to run applications in an environment that provides advanced features that are beyond the scope of existing cloud resources.
5) Will I get the same thing if I use the Docker resource in Heat?
No, the Docker Heat resource does not provide a resource scheduler, or a choice of container technology used. It is specific to Docker, and uses Glance to store container images. It does not currently allow for layered image features, which can cause containers to take longer to start than if layered images are used with a locally cached base image. Magnum leverages all of the speed benefits that Docker offers, and implements Kubernetes and Mesos as alternate choices to Docker Swarm for container orchestration.
6) What does multi-tenancy mean in Magnum (Is Magnum Secure)?
Resources such as Clusters are started by Magnum can only be viewed and accessed by users of the tenant that created them. Clusters are not shared, meaning that containers will not run on the same kernel as neighboring tenants. This is a key security feature that allows containers belonging to the same tenant to be tightly packed within the same Pods and Clusters, but runs separate kernels (in separate Nova Instances) between different tenants. This is different than using a system like Kubernetes without Magnum, which was originally designed to be used only by a single tenant, and leaves the security isolation design up to the implementer. Using Magnum provides the same level of security isolation as Nova provides when running Virtual Machines belonging to different tenants on the same compute nodes.

Zun Installation Guide

Install and configure OpenStack Pike with Kolla as a standalone

Kolla is an OpenStack project focused on deploying, maintaining, and upgrading easily production OpenStack clouds following the community best practices. To achieve this goal, Kolla uses two main technologies: Ansible automation scripts and Docker containers. As you will see, it is really easy to deploy and maintain OpenStack using Kolla.
OpenStack Kolla Logo

Prerequisites

For this lab, we will deploy Ocata which is the last stable version of OpenStack on a single machine. This kind of deployment is also known as All-In-One (AIO). Kolla is supported on CentOSOracle Linux and Ubuntu.

Linux distribution

We will use a Ubuntu 16.04 VM with 4 vCPU, 8 GB of RAM and 40 GB of disk. Depending on the number of OpenStack services you are willing to install, you may have to add more RAM and more disk space.

Networking

The VM will have two NICs configured with a static IP. The first NIC will have the IP 10.10.20.31/24, the second NIC will have the IP 10.10.20.32/24, and the gateway will be 10.10.20.1/24. We will also need two virtual IPs for HAproxy and we will use 10.10.20.30/24 for the external virtual IP and 10.10.20.33/24 for the internal virtual IP.

Upgrade Ubuntu 16.04 LTS

1- Update the the APT repository.
$ sudo apt-get update
2- Upgrade your system.
$ sudo apt-get upgrade

Configure the network

1- The first interface (ens192 in my case) should have an IP and the second interface (ens224 in my case) should be down.
$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       validlft forever preferredlft forever
    inet6 ::1/128 scope host 
       validlft forever preferredlft forever
2: ens192:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:01:1e:8c brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.31/24 brd 10.10.20.255 scope global ens192
       validlft forever preferredlft forever
    inet6 fe80::250:56ff:fe01:1e8c/64 scope link 
       validlft forever preferredlft forever
3: ens224:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:50:56:01:1e:8e brd ff:ff:ff:ff:ff:ff
2- Edit the network configuration file.
$ sudo vim /etc/network/interfaces
3- Add the following lines to your network configuration file to get an IP from the DHCP server (you can of course use a static IP if you wish). Replace [second_nic_label] with the label of your interface.
# The secondary network interface
auto [second_nic_label]
iface [second_nic_label] inet static
        address 10.10.20.32
        netmask 255.255.255.0
4- Restart the network.
$ sudo systemctl restart networking
5- Check if your second network card got an IP.
$ sudo ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       validlft forever preferredlft forever
    inet6 ::1/128 scope host 
       validlft forever preferredlft forever
2: ens192:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:01:1e:8c brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.31/24 brd 10.10.20.255 scope global ens192
       validlft forever preferredlft forever
    inet6 fe80::250:56ff:fe01:1e8c/64 scope link 
       validlft forever preferredlft forever
3: ens224:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:01:1e:8e brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.32/24 brd 10.10.20.255 scope global ens224
       validlft forever preferredlft forever
    inet6 fe80::250:56ff:fe01:1e8e/64 scope link 
       validlft forever preferredlft forever

Install Kolla Dependancies

$ sudo apt-get install python-jinja2 python-pip libssl-dev
$ sudo pip install --upgrade pip
$ sudo pip install ansible

Install and configure Kolla

1- Install kolla-ansible.
$ sudo pip install kolla-ansible==6.0.0.0rc2
2- Copy the configurations files.
$ sudo cp -r /usr/local/share/kolla-ansible/etc_examples/kolla /etc/kolla
3- Edit the Kolla configuration.
$ sudo vim /etc/kolla/globals.yml
4- Modify the following values. Modify [first_nic_label], and [second_nic_label] accordingly.
kolla_base_distro: "centos"
kolla_install_type: "binary"
openstack_release: "pike"
kolla_internal_vip_address: "10.10.20.33"
kolla_external_vip_address: "10.10.20.30"
network_interface: "[first_nic_label]"
neutron_external_interface: "[second_nic_label]"
kolla_enable_tls_external: "yes"
kolla_external_fqdn_cert: "{{ nodeconfigdirectory }}/certificates/haproxy.pem"
5- Generate a self-signed TLS certificate for the HAProxy external interface. It will be stored in /etc/kolla/certificates. You can of course also use a signed certificates if you have one.
$ sudo kolla-ansible certificates
6- Use QEMU instead of KVM (you can skip this step if your host supports hardware virtualization).
$ sudo mkdir -p /etc/kolla/config/nova
$ sudo vim /etc/kolla/config/nova/nova-compute.conf
Add the following lines:
[libvirt]
virt_type = qemu
cpu_mode = none
7- If you are deploying a nested environment (your host is a VM), you need to enable promiscuous on your virtual network. If you don't do this, your instances will not have external connectivity.
8- Generate password for the deployment.
$ sudo kolla-genpwd
9- Bootstrap the server.
$ sudo kolla-ansible \
-i /usr/local/share/kolla-ansible/ansible/inventory/all-in-one \
bootstrap-servers
10- Verify if the bootstrap was successful.
localhost: ok=40   changed=20   unreachable=0    failed=0
11- Pull the different Docker images needed by Kolla.
$ sudo kolla-ansible pull

Deploy OpenStack using Kolla

1- Check the environment.
$ sudo kolla-ansible prechecks \
-i /usr/local/share/kolla-ansible/ansible/inventory/all-in-one
2- Verify if the precheck was successful.
localhost: ok=83   changed=1    unreachable=0    failed=0
3- Deploy OpenStack.
$ sudo kolla-ansible deploy \
-i /usr/local/share/kolla-ansible/ansible/inventory/all-in-one
4-Verify if all the containers are up and running.
$ sudo docker ps -a
5- Generate the admin-openrc.sh configuration file.
$ sudo kolla-ansible post-deploy
6- Install the openstack CLI client.
$ sudo pip install python-openstackclient
7- Edit the init-runonce file.
$ sudo vim /usr/local/share/kolla-ansible/init-runonce
8- Modify the public network scheme.
EXT_NET_CIDR='10.10.20.0/24'
EXT_NET_RANGE='start=10.10.20.110,end=10.10.20.254'
EXT_NET_GATEWAY='10.10.20.1'
9- Get the root privileges.
$ sudo -s
10- Load the environment variable needed by the OpenStack CLI
# source /etc/kolla/admin-openrc.sh
11- Initialize the deployment.
# cd /usr/local/share/kolla-ansible/ && ./init-runonce

Access the Horizon console

1- Get the admin user password.
$ sudo grep keystone_admin_password /etc/kolla/passwords.yml
2- Browse to the external virtual IP https://10.10.20.30 and login with the user "admin" and the password from the previous step.
OpenStack Horizon Login Page
At this point you should have a working deployment of OpenStack Ocata. If you want to add more services like Cinder (block storage) or Swift (object storage), please refer to the specific annexes.

Annexes

Kolla management

Destroy the OpenStack deployment

1- Delete all the instances in your OpenStack environment.
2- Destroy the OpenStack deployment.
$ sudo kolla-ansible destroy --yes-i-really-really-mean-it

Stop the deployed containers

1- Go in the tools directory.
$ cd /usr/local/share/kolla-ansible/tools
2- Stop the containers
$ sudo ./stop-containers

Remove the deployed containers

1- Go to the tools directory.
$ cd /usr/local/share/kolla-ansible/tools
2- Remove the containers
$ sudo ./cleanup-containers

Remove the network modification done by Neutron.

1- Go to the tools directory.
$ cd /usr/local/share/kolla-ansible/tools
2- Clean the network.
$ sudo ./cleanup-host

Remove the containers images stored in the local registry.

1- Go to the tools directory.
$ cd /usr/local/share/kolla-ansible/tools
2- Clean the images.
$ sudo ./cleanup-images

How to Install Docker CE on CentOS 8 and RHEL 8

  Docker  is a daemon-based container engine which allows us to deploy applications inside containers.  Docker is available in two versions,...