==================================================================
Since I tagged this repo, users may expect communication from me.
My work here (writing this on Tuesday, the 30th of October, 2018) is not ready for re-use, and will be by Xmas Eve, as my Merry Christmas to Microsoft Inc.
That first usable version will be released as [3.0.0-xmas]. I will consider authorizing branching/collaboration on this repo, only after that 3.0.0-xmas release.
In the meantime don't be shy about asking anything, especially if you think it's out of your reach: I love proving people they are much more thant they think. I will very happily answer you, just try and make your question as clear and short as possible. The clearer and the shorter you question will be, the faster you'll get an answer. Submit an issue here for any question.
Any previous release is just for my personal project management automation. (I have in house 24 U stack + 2 zero-U PDUs )
I wil never provide ansible / terraform recipe for that repo : those are things company will have to pay, to get.
You may request my services, by submitting an issue with a github account, I will then find you, you don't need to write any email contact or phone number. Don't bother asking me if I would fly 11 000 miles to work on a project: I will, especially I f don' understand a word of your native language.
All in all, 3.0.0-xmas release will provide you a way to say f*** u to microsoft buying github.com, and you will find out how then, but for now, consider :
If you see anything written in French, just don't pay atention. You may, but be informed that I use french to mislead my business conccurent, and what you see in mess here, is in mess on purpose. Indeed, as any social network, Github is massively used to gather intel about IT professionals. Massive doesn't mean bad. Massive means there has to be mean stuff around, it's a statistical fact. Just as if you would pick a random person in the street. Along with the usual source code/build artefacts/apps.
Sit back, have some fine French Cheese, and see you on christmas :)
Thank you for reading me,
I heard Linus Torvalds say Linux is nothing, compared to Git.
And I agree with him.
J.B. Lasselle
Lancer l'évolution Free IPA server pour :
Eténdre Free IPA pour la gestion de l'inventaire matériel, sans automatisation de la gestion du réseau d'alimentation électrique, kje m'arrête au niveau Wake ON LAN.
Ce repo versionne la recette de provision de l'infrastrcuture interne Kytes.
Gitlab CE
TODOs:
Ajouter la provision LetsEncrypt avec une intégration pour le HTTPS Gitlab, avec un conteneur Lets Encrypt seul (Lets Encrypt hors Free IPA server).
Ajouter dans cette documentation le cycle de gestion de l'autorité de certification (Lets Encrypt hors Free IPA server).
Ajouter la provision serveur DNS, avec intégration pour cohérence avec la configuration NGINX (serveur DNS hors Free IPA server)
Ajouter dans cette documentation le cycle de gestion du serveur DNS (serveur DNS hors Free IPA server).
Changer cette recette pour qu'elle utilise le serveur DNS et le Lets Encrypt compris dans Free IPA server, au lieu du letsencrypt et du serveur DNS standalone utilisés précédemment.
Ajouter dans cette documentation le cycle de gestion de l'autorité de certification Lets Encrypt incluse dans Free IPA server.
Ajouter dans cette documentation le cycle de gestion du serveur DNS inclut dans Free IPA server.
Ajouter une automatisation des opérations Backup / Restore :
./backup.sh
: il prendra en argument, un chemin, le chemin du répertoire dans lequel le zip des fichiers de backup est conservé. le zip contient:.env
,./restore.sh
: celui-là est secret.Quelquies dépendances, qui nécessitent une templatisation Jinja 2 / Ansible :
Le numéro de port interne au conteneur docker nginx, déclaré dans le ./docker-compose.yml
:
listen
dans le fichier ./infra-kytes/nginx/gitlab.conf
.listen
dans le fichier ./infra-kytes/nginx/rocketchat.conf
.Le numéro de port interne au conteneur gitlab, déclaré dans le ./docker-compose.yml
, pour s'interfacer au nginx interne au conteneur gitlab :
./docker-compose.yml
, via le fichier ./.env
, et la varible d'environnement GITLAB_HTTP_PORT_VIA_NGINX_INTERNE_GITLAB
../infra-kytes/nginx/gitlab.conf
, pour la directive proxy_pass
Le numéro de port interne au conteneur rocketchat, déclaré dans le ./docker-compose.yml
, pour s'interfacer au nginx interne au conteneur gitlab :
./docker-compose.yml
, via le fichier ./.env
, et la variable d'environnement NUMERO_PORT_ECOUTE_ROCKETCHAT
. La variable d'environnement PORT=$NUMERO_PORT_ECOUTE_ROCKETCHAT
, propre à la distribution de l'image docker rocketchat, est utilisée pour cette configuration, cf. la section environment:
de la configuration du service rockerchat
, dans le ./docker-compose.yml
../infra-kytes/nginx/rocketchat.conf
, pour la directive proxy_pass
Les noms d'hôtes réseau docker utilisés dans les configurations reverse proxy, doivent correspondre aux décalrations container_name
, dans le fichier ./docker-compose.yml
, pour les conteneurs respectifs.
Pour exécuter cette recette une première fois :
export PROVISIONING_HOME=$HOME/infra-kytes
mkdir -p $PROVISIONING_HOME
cd $PROVISIONING_HOME
git clone "https://github.com/Jean-Baptiste-Lasselle/infra-kytes" .
chmod +x ./operations.sh
./operations.sh
Soit, en une seule ligne :
export PROVISIONING_HOME=$HOME/infra-kytes && mkdir -p $PROVISIONING_HOME && cd $PROVISIONING_HOME && git clone "https://github.com/Jean-Baptiste-Lasselle/infra-kytes" . && chmod +x ./operations.sh && ./operations.sh
Toujours en une seule ligne, mais en mode verbeux :
export PROVISIONING_HOME=$HOME/infra-kytes && mkdir -p $PROVISIONING_HOME && cd $PROVISIONING_HOME && git clone "https://github.com/Jean-Baptiste-Lasselle/infra-kytes" . && chmod +x ./operations-verbose.sh && ./operations-verbose.sh
La provision de cette infrastructure est configurable à l'aide du fichier ".env" présent à la racine de ce repo. Pour l'ensemble de ces variables, le tableau ci-dessous explicite le rôle de chacune, il est à noter que la notion d'utilisateur intiial Kytes, correspond à la notion d'administrateur de l'infrastructure Kytes.
Les variables d'environnement utilisables sont :
Variable | Configure |
---|---|
KYTES_USERNAME_UTILISATEUR_ADMIN_INITIAL |
Le username du premier utilsiateur admin initial |
KYTES_MDP_UTILISATEUR_ADMIN_INITIAL |
Le secret du premier utilisateur admin initial |
( "secret" :un mot de passe, ou un "token"...) | |
KYTES_EMAIL_UTILISATEUR_ADMIN_INITIAL |
L'adresse email du premier utilsiateur admin initial |
ADRESSE_IP_SERVEUR_DNS |
L'adresse IP du servveur DNS de l'infrastructure Kytes |
GITLAB_CE_VERSION |
La version de Gitlab CE utilisée |
POSTGRES_VERSION |
La version de PostGReSQL utilisée pour la BDD de Gitlab |
REDIS_VERSION |
La version de Redis utilisée pour la BDD de Gitlab |
NOM_DU_RESEAU_INFRA_DOCKER |
Le nom du réseau DOcker Bridge, dans la cible de déploiement Hôte Docker |
GITLAB_HOST |
La valeur qui sera donnée à la variable d'environnement GITLAB_HOST du conteneur Gitlab |
GITLAB_SSH_IP |
L'adresse IP par laquelle le serveur Gitlab sera accessible par SSH, depuis l'extérieur |
GITLAB_SSH_PORT |
Le numéro de port par lequel le serveur Gitlab sera accessible par SSH, depuis l'extérieur |
GITLAB_HTTP_IP |
L'adresse IP par laquelle le serveur Gitlab sera accessible par HTTP, depuis l'extérieur |
GITLAB_HTTP_PORT |
Le numéro de port par lequel le serveur Gitlab sera accessible par HTTP, depuis l'extérieur |
GITLAB_HTTPS_IP |
L'adresse IP par laquelle le serveur Gitlab sera accessible par HTTPS, depuis l'extérieur |
GITLAB_HTTPS_PORT |
Le numéro de port par lequel le serveur Gitlab sera accessible par HTTPS, depuis l'extérieur |
TZ |
La "Time Zone" qui sera utilisée par l'instance Gitlab, exemple TZ=Europe/Paris . Des tests pour l'intégration à la configuration NTP dans l'OS de l'hôte Docker sous jacent, sont à faire. |
LETSENCRYPT_EMAIL |
L'adresse email qui sera utilisée pour l'intégration LetsEncrypt |
VERSION_IMAGE_FREE_IPA_SERVER |
La version de l'image docker FREE IPA SERVER utilisée |
VERSION_IMAGE_LETSENCRYPT |
La version de l'image docker LETSENCRYPT utilisée |
VERSION_IMAGE_NGINX |
La version de l'image docker NGINX utilisée |
Rappel, à propos du fichier .env
Docker
Attention,un piège existe quant à ces variables d'environnement, et leur interpolation :
Lorsque vous précisez une valeur de variable d'environnement dans le ./docker-compose.yml
(ou un Dockerfile
), et que :
docker-compose.yml
, vous avez le contenu :
rocketchat:
container_name: "$NOM_CONTENEUR_ROCKETCHAT"
image: coquelicot/rocket.chat:1.0.0
build:
context: ./rocketchat/construction/
args:
- UNEVARIABLE_ENV_ROCKETCHAT_PAR_EXEMPLE="$VALEUR_UNEVARIABLE"
./.env
, vous avez le contenu :
UNEVARIABLE=bernard
Alors, la valeur envoyée sera "bernard"
, et non la valeur bernard
!!! (ce qui m'a causé quelques soucis pour passer
certaines valeurs, comme des mots de passes ....)
Lorsque vous aurez exécuté une première fois l'instruction en une ligne ci-dessus, vous pourrez faire un cycle IAAC, sans re-télécharger d'image extérieures, en reconstruisant toutes les images qui ne sont pas téléchargées, avec :
export PROVISIONING_HOME=$HOME/infra-kytes && cd $PROVISIONING_HOME && docker-compose down && cd .. && sudo rm -rf $PROVISIONING_HOME && mkdir -p $PROVISIONING_HOME && cd $PROVISIONING_HOME && git clone "https://github.com/Jean-Baptiste-Lasselle/infra-kytes" . && chmod +x ./operations.sh && ./operations.sh
La commande ci-dessus, modulo la première exécution de cette recette exécutée, est idempotente
# Infra Kytes
192.168.1.30 rocketchat.kytes.io
192.168.1.30 gitlab.kytes.io
# Hôte Docker, VM constituant l'infrastructure de déploiement.
192.168.1.30 production-docker-host-1.kytes.io
Dans le run, j'ai constaté que la seule manière de tout relancer correctement étaient de tout détruire et re-construire, jusqu'au build des images, et ce avec sudo, pour pouvoir reprendre en main les répertoires mappés en tant que docker volumes :
sudo docker-compose down --rmi all && docker-compose up -d --force-recreate
ceci n'est pas satisfaisant. Ceci st du au plongeur soudeur, et il y a quelque chose de très intéressant à faire en terme de disnction entre la recette de provision, et les opérations standards de déploiemùent, ainsi que leur tests. C'est RocketChat et le healthcheck de mongoDB qui ont posé problème. repo historique des ops. repos des operatiosn standars. toutes les références des opérations standards .... chaque recette doit avoir une automatisation du logging des valeurs des arguments à l'invocation, de l'env, le whoami, les réréfrences vers n commit, sur N repos git, correspondant à N répertoires versionnés dans l'env d'exécution du soft (un conteneur).