Avec copier, on a tout en yml. Ce que je souhaite :

• pouvoir être DRY(Don’t repeat yourself)
• avoir un mécanisme d’héritage ou apparenté qui me permette d’appliquer plusieurs templates en même temps
• ça soit intégrable en CI avec immutabilité
• avoir la possibilité de créer des sous-templates (par exemple pour gérer les roles d’une collection ansible)

Du coup, j’ai conçu un petit script en python pour étendre copier en m’appuyant sur la doc de copy:

https://copier.readthedocs.io/en/stable/api/

Avec son système de sous-répertoires, on va faire nos diverses variations.

Organizing cookiecutters in directories (1.7+) - cookiecutter 1.7.2 documentation

Le problème avec cookiecutter c’est que pour l’instant il n’existe pas de méthodes pour générer une arborescence de dossiers à partir d’une liste.

Imaginons un repo ansible, on voudrais pouvoir définir des roles, et pour chacun des roles, on voudrait définir le dossier de tests molecule et le playbook de base qui va avec.

Du coup, on aurait une sorte de sous-template comme ça :

roles     ->role1
          ->role2
molecule  ->role1
          ->role2
playbooks ->role1
          ->role2

Donc, on voudrait générer ça à partir d’une liste:

{
  roles: [
    role1
    role2
  ]
}

On s’appuit sur l’idée de base ici :

Creating cookiecutter multiple sub-folders from template

mais il y a des trucs qui ne fonctionnent pas.

On doit se battre en plus avec le fait que cookiecutter a des fichiers de config en json et en yml.

Ça rend les choses compliquées (et instables) dés qu’on a des tableaux complexes.

Donc :

• renovate
• semantic-release

On va les coder simplement sans fioritures et on les refactorera une fois qu’on aura retrouvé tous nos outils de CI.

On va d’abord coder le role ansible container. Ce role aura la charge de faire toutes les tâches nécessaires à la création d’un container avec ansible.

C’est lui qui installe l’entrypoint ou les dossiers selon la XDGBase Directory Spec.

Il paramètre aussi l’ensemble des déclarations de l’image container résultante.

On cherche aussi à utiliser un inventaire en yml avec molecule au lieu du fichier hosts en INI.

Cela afin d’avoir une syntaxe semblable sur l’ensemble du projet.

Je voudrais automatiser la création de README selon un template et la création de la doc.

Pour cela, on va utiliser le paquet

kefranabg/readme-md-generator

et un template selon ce paquet pour générer automatiquement notre README.

Ce générateur en nodejs me pose quand même quelques soucis. Il n’est pas maintenu depuis 2 ans et est vraiment spécifique à nodejs.

Du coup, stand-by et on va réfléchir au truc.

la génération de doc pour shell semble se faire avec

https://github.com/reconquest/shdoc

sans problèmes.

Reste à tester

https://github.com/thegeeklab/ansible-doctor

et

https://www.npmjs.com/package/doctoc

Passons maintenant à la mise en place d’un environnement nodejs pour pouvoir restaurer les containers renovate et semantic-release.

C’est bon à l’exception de Gitlab qui met n’importe quoi comme nom de commit, comme d’habitude.

Le projet ansible-environments c’est la collection ansible qui fournit les environnements de base des langages sécurisés et paramétrés pour la prod.

Son pendant Inspec ce sont les profils Inspec chargés de tester ces environnements.

Nous avons aussi créé un projet qui centralise les artefacts nécessaires à tous les repos.

Ces artefacts sont en vrac :

• CONTRIBUTING.md
• LICENSE.md
• Des gitlab-ci.yml de lint et release
• Des presets de release
• Des presets de renovate

security.txt a été oublié, il faudra l’ajouter.

Pourquoi ?

Parce que je suis à peu près à 80 repos git actifs pour le projet de forge logicielle.

C’est trop, ça introduit des instabilités partout et une capacité de progression réduite (PR en attentes…)

Pourquoi je n’ai pas monorepoysé plus tôt ?

Parce que je crains le repo fourre-tout et les monorepos ont tendance à aller dans cette direction.

Du coup, on va réfléchir nos monorepos.

Je propose donc:

• monorepo services de la forge logicielle
• monorepo outils de la forge logicielle.
• monorepos cucumber et Inspec correspondants (donc 4 monorepos)

Les services de la forge logicielle sont les containers qui tournent en permanence (Gitea, Concourse-ci, etc…)

les outils de la forge logicielle sont les containers appellés pour résoudre une tâche (ansible, inspec, etc…)

Il y a un container qui fonctionne comme un service mais qui est un outil (plus une sorte de container side-car), c’est renovate. Donc lui, je vais le gérer dans le monorepo des outils.

Je passe donc mon temps à chercher des infos dans le code et faire divers tests pour trouver les paramètres que GoHarbor accepte.

Portal m’a fait ressurgir des limbes de mon cerveau la notion d’héritage de templates jinja2 au sein d’ansible.

Avec ça je peux modifier le template vhost de base de nginx avec une variante locale (spécifique à GoHarbor).

Dans le cadre des collections ansible, il peut être nécessaire d’installer les collections dans le projet lui-même en exécutant une commande du type :

ansible-galaxy collection install -r requirements.yml -p ./collections

Cela permet d’utiliser des chemins relatifs dans la déclaration extends des templates jinja2.

L’init passe si on n’oublie pas de paramétrer le répertoire container-init qui contient le fichier LOCK déclenchant le démarrage des autres containers.

Paramétrer veut dire le créer et lui affecter le USER du container init.

Maintenant, on débugge les valeurs manquantes dans les fichiers de config de GoHarbor.

GoHarbor a besoin de 3 interfaces publiques:

• celle de core qui gère l’accès à l’API REST
• celle de portal qui gère l’accès à l’interface web de gestion
• celle du registry qui gère les push et pull des images

Donc, on doit créer 3 noms domaines pour les tests:

• core.coppint.test
• web.coppint.test
• registry.coppint.test

Ces noms de domaines ont leur port définis sur 444, 443 et 445 depuis l’extérieur.

Un doute m’assaille quand même sur la façon dont portal se connecte au backend.

En effet, il n’apparait nulle part, côté portal, de paramètres qui permette de déterminer l’uri des backends.

Du coup, on va tâtonner. On va faire le fichier docker-compose au mieux, le faire tourner et voir à quoi ressemble l’interface web (portal quoi !).

standalone-db-migrator a besoin de paramètres postgres pour se connecter à la DB et faire ses migrations. Il utilise les même paramètres que core dont SSL_MODE qu’on peut mettre à verify-full et ça c’est cool !!!!!

Du coup, il ne faut pas oublier de monter le couple clé/certificat TLS plus la chaîne de certification dans les répertoires client de postgres. Et ça fait du mTLS. En plus de celà, il faut extraire les fichiers SQL de migration et les monter dans le container init avec un bon POSTGRES_MIGRATION_SCRIPTS_PATH.

Jusqu’à présent, on utilisait le paramètre delegate_to pour accéder à l’environnement du container.

Maintenant, on va le déclarer dans l’inventaire et y accéder à partir de l’inventaire. L’inventaire sera divisé en 3 parties :

• la première construit le container de base et le provisionne avec l’environnement python nécessaire à ansible
• la deuxième partie provisionne le container en se servant de la déclaration du container dans l’inventaire (plus besoin de delegate_to)
• la troisième partie conclut le container. C’est à dire qu’il lui ajoute ses déclarations de containérisation (CMD, USER, …)

Vient la construction du docker-compose.yml. C’est celui qui contient le plus de containers au sein du projet de forge logicielle.

Quelques éléments :

• Le TLS se fait avec les variables d’environnement INTERNAL_TLS_ENABLED
• Le container registryctl a un point de montage commun avec le container registry qui contient le fichier de configuration de registry

Donc, on finit les tests Inspec avec un patch à merger :

nginx parsed config as attribute by micheelengronne · Pull Request #44 · dev-sec/nginx-baseline

Et on se replonge dans GoHarbor.

on va pouvoir ajouter Portal à la liste de nos containers GoHarbor en utilisant le role ansible nginx et en incorporant le code html extrait de la phase de compilation.

Portal se construit avec la task synchronize d’ansible qui a une syntaxe différente de copy pour pourvoir uploader le code html.

Le débuggage de cette étape au prochain épisode.

Il y a un problème à régler avec nginx en container. Quelle est la bonne architecture ?

Les tests seront de 2 types, internes et externes.

• Les tests internes vont vérifier la configuration de nginx.
• Les tests externes vont vérifier que nginx produit bien des pages web accessibles depuis l’extérieur.

On va formaliser ces tests avec :

inspec/inspec

Avec Inspec, les tests internes seront différenciés par le fait qu’ils seront exécutés dans l’environnement distant.

Pourquoi l’environnement distant ?

Parceque nous n’exécutons jamais Inspec au sein de l’environnement testé. Cela afin d’éviter des biais de test entre le dev, le staging et la prod.

Nos tests Inspec pour nginx sont basés sur :

dev-sec/nginx-baseline

J’ai donc créé un PR pour soft-coder l’emplacement des fichiers de configurations nginx. Cela permettra de rendre le profil compatible avec des installs qui utilisent la XDGBase Directory Specification :

softcoded nginx path by micheelengronne · Pull Request #43 · dev-sec/nginx-baseline

Pour la disposition des couples clé/certificat TLS et le certificat de la chaîne de confiance, je place tout ça dans $HOME/.ssl par analogie avec la disposition de ssh. Je nomme les fichiers selon le nom de domaine qu’ils signent. Le certificat de la chaîne est nommé root.crt en rappel de la façon de nommer chez Postgres.

La génération de Diffie-Helman est longue mais m’a donné une idée. Un service qui génère à l’avance du Diffie-Helman. Il en existe déjà un basé sur dhtools :

Public Diffie-Hellman Parameter Service/Tool

Donc un deuxième service serait pas mal (avec des fonctionnalités supplémentaires) ?

Pour celà on va modifier et mettre à jour un vieux profil Inspec et l’adapter aux nouvelles façons de concevoir le code.

La question est de savoir si il est pertinent d’installer nginx en container en respectant l’arborescence classique adaptée aux multi-users ou si il vaut mieux faire une arborescense mono-user selon les standards de containerisation.

On part donc sur une installation mono-user respectant la XDG_Base_Directory.

XDG Base Directory

Pour les paramètres qui changent au démarrage du service, on souhaite n’utiliser que des variables d’environnement, comme dans tous les containers.

Ça veut dire que dans le cas de nginx, on va se servir de perl :

Docker environment variables and NGINX

La subtilité du container portal c’est que le code est un package nodejs qui ne provient pas d’un repo mais est extrait localement depuis la phase de compilation.

Donc, on va devoir faire avec pour le moment.

Plus tard, quand un repo npm sera installé, on uploadera ce paquet dans le repo dans une phase préparatoire (depuis un projet à part) et on utilisera ce paquet correctement installé depuis le repo.

Pourquoi ?

Pour profiter du système de dépendances de npm et ainsi coder d’autres packages qui se greffent à celui-là.

Mais pour ce soir, on va faire simple.

Premier truc à modifier, c’est l’appel des images containers depuis le docker-hub. En effet, pour éviter de heurter l’API rate limiting, on va essayer de changer ces appels et les remplacer par nos propres images.

On va placer le code de portal dans le répertoire /home/goharbor/srv car nos containers ne tournent pas en root et sont mono USER donc le code doit se trouver dans le HOME de ce USER.

Pourquoi srv ?

Parce que le code de portal est considéré comme du code nécessaire à exécution du service au sein du container.

Pour ref:

Where should the web server root directory go in linux?

Pour bien faire les choses, on va créer un role dans la collection ansible qui configure les environnements de base.

Ce role paramétrera nginx de façon sécurisée et il sera utilisé pour portal.

Pour les tests bats, on va tester l’upload, le download et l’access control d’images dans le Docker registry.

Le problème c’est qu’on ne peut pas utiliser la commande Docker pour ça. Pourquoi ? Parceque dans DinD, le processus Docker est lié à l’host sous-jacent et donc on peut se retrouver à avoir des disparités et des instabilités dans les tests dus aux réglages différents des host.

À noter au propre, les schémas de DinD depuis Instagram.

podman ayant un output différent, il faut écrire les tests en fonction.

Finalement les tests bats sont passés, le merge est fait et les artefacts de prod réalisés (container init et container registry).

On va donc pouvoir faire les tests côté GoHarbor.

On va donc faire des suites de tests bats pour s’assurer que notre container (à notre sauce) faisant tourner le registre officiel fonctionne bien.

Les suites de tests sont :

• contrôle d’accès
• upload et download

C’est des suites de tests de base. la grande majorité des tests sera faite au niveau de GoHarbor.

On a besoin malgré tout d’un container init pour créer un fichier de configurations minimaliste dont se sert registry.

L’essentiel de la configuration peut être pourtant gérée avec des variables d’environnement.

Le registre peut aussi avoir redis greffé, c’est cool.

Finalement, on a pas beaucoup avancé mais on a appris des trucs.

On va d’abord revenir sur la gestion des configurations dans les containers GoHarbor.

En effet, hier, on avait déterminé 3 types de configurations :

• L’hyperstatique
• La statique
• La dynamique

Ces caractérisations sont superflues et on va simplifier ça avec la norme :

XDGBaseDirectorySpecification

Dans notre cas, nous allons gérer les templates de configuration au niveau du container init. Il aura la charge des les mettre dans les bons répertoires si il peut y accéder et si un fichier équivalent n’est pas déjà présent.

Après avoir essayé de compiler le registry officiel de docker, nous nous sommes rendu compte que la dernière release avait 2 ans et que sa façon de compiler avait changé.

Release registry 2.7.1 · docker/distribution

La mort dans l’âme, nous nous sommes résignés à utiliser un commit plutôt qu’un numéro de version pour assurer l’immutabilité et utiliser un code récent.

Merge pull request #3314 from crazy-max/dummy · docker/distribution@35f1369

Et la compilation a trés bien marché. On a un beau binaire registry qu’on va pouvoir mettre en container lundi.

En plus, on va faire un container à notre sauce avec le projet officiel de docker registry.

docker/distribution

Pourquoi ? Parceque Goharbor s’appuie sur le registre officiel de Docker en backend.

Il y a deux types de containers. Un qui gère des binaires et l’autre qui gère du nodejs.

Ces deux types ne faisant pas appel au même language de programmation et donc au même environnement, leurs configurations vars.yml doivent être différentes.

On va donc construire les containers binaires avec le role coppint.environment.binaries et le container nodejs avec le role coppint.environment.nodejs.

Le container harbor_core ne semble pas charger de configuration par défaut (ou il la charge silencieusement). Il faut donc trouver comment charger un fichier de configuration spécifique.

C’est semble-t-il le cas de l’ensemble des binaires. Cela semble être géré par des variables d’environnement. C’est plutôt cool dans un environnement conteneurisé !

Les fichiers de configurations au sein des containers sont de nature variée et donc doivent être gérés de façon différente.

Nous avons des fichiers de configuration hyperstatiques qui peuvent être gérés comme du code.

Nous avons des fichiers de configuration statiques qui peuvent être gérés par du templating ansible et sont valables pour la durée de vie du container-image.

Et nous avons des fichiers de configuration dynamiques qui sont gérés par dockerize au moment de l’initialisation du service.

Sur le plan des bases de données, GoHarbor n’a pas de base propre. Il utilise la base de données du projet docker/distribution.

Nous voulons uniquement ceux de Goharbor et pas des dépendances externes.

Les dépendances externes (Redis, nginx, postgres) ont ou auront leurs propres projets.

Premier travail de ce soir, déployer GoHarbor avec l’installer officiel pour déterminer quels containers sont créés et quels sont les fichiers de configuration générés.

On va donc tester ça dans un vagrant en local.

Le script nécessite sudo partout. C’est terrible dans un environnement de prod.

Bien sûr, ne pas oublier de faire tout ça dans un sous-répertoire de /vagrant sinon on perd tout au prochain vagrant destroy.

Après avoir générer les certificats TLS comme indiqué ici :

Harbor - Configure HTTPS Access to Harbor

et mis tout ça dans les bons répertoires, le script sudo ./prepare --with-notary --with-trivy --with-clair --with-chartmuseum semble fonctionner :

prepare base dir is set to /vagrant/harbor-test/harbor
Generated configuration file: /config/portal/nginx.conf
Generated configuration file: /config/log/logrotate.conf
Generated configuration file: /config/log/rsyslog_docker.conf
Generated configuration file: /config/nginx/nginx.conf
Generated configuration file: /config/core/env
Generated configuration file: /config/core/app.conf
Generated configuration file: /config/registry/config.yml
Generated configuration file: /config/registryctl/env
Generated configuration file: /config/registryctl/config.yml
Generated configuration file: /config/db/env
Generated configuration file: /config/jobservice/env
Generated configuration file: /config/jobservice/config.yml
loaded secret from file: /data/secret/keys/secretkey
Copying nginx configuration file for notary
Generated configuration file: /config/nginx/conf.d/notary.upstream.conf
Generated configuration file: /config/nginx/conf.d/notary.server.conf
Generated configuration file: /config/notary/server-config.postgres.json
Generated configuration file: /config/notary/server_env
loaded secret from file: /data/secret/keys/defaultalias
Generated configuration file: /config/notary/signer_env
Generated configuration file: /config/notary/signer-config.postgres.json
Generated configuration file: /config/clair/postgres_env
Generated configuration file: /config/clair/config.yaml
Generated configuration file: /config/clair/clair_env
Generated configuration file: /config/clair-adapter/env
Generated configuration file: /config/trivy-adapter/env
Generated configuration file: /config/chartserver/env
Generated configuration file: /compose_location/docker-compose.yml
Clean up the input dir

Du coup on tente l’install.

L’install est très instable mais elle donne un docker-compose.yml et une liste de containers et de configurations. Le but est de réduire le scope des containers propres à GoHarbor et d’évacuer les containers des services associés vers leurs propres projets (redis, postgres et éventuellement notary, clair, etc…).

En fouillant dans les projets officiels, je trouve des surprises. Notary, par exemple, n’a pas de release depuis quasiment 2 ans :

Publish a release · Issue #1583 · theupdateframework/notary

Pour chartmuseum, on est à quasiment 1 an :

Release ChartMuseum v0.12.0 · helm/chartmuseum

Kubernetes et donc Helm/Chart (vu qu’on veut faire du Gitops) ne sont pour le moment pas dans le scope du projet de forge logicielle, donc chartmuseum sera réévalué plus tard.

Au final, on a 3 binaires :

• harbor_core
• harbor_jobservice
• harbor_registryctl

Et un package nodejs : portal

On a deux helpers à compiler aussi :

• migrate-patch
• standalone-db-migrator

Du coup, la story va consister à créer les containers harbor_core, harbor_jobservice, harbor_registryctl, un container init (avec les migrate) et le container portal.

On va faire communiquer tout ça ensemble avec les containers officiels postgres, redis et nginx.

On va appliquer des features cucumber et un profil Inspec là-dessus.

Puis, dans un second temps, on va ajouter les scanners et notary.

Tout ça pour ce projet de forge logicielle.

Ce soir, on va démarrer la mise en containers de GoHarbor.

L’idée est de récupérer les binaires créés au sein du script d’install de GoHarbor.

Ensuite, on les installe à notre sauce :

• Container créé avec ansible
• Init scripts avec pre-hook et post-hook
• Pas de compilation au sein des containers
• Tests dynamiques créés avec Cucumber
• Tests statiques créés avec Inspec (CINC-auditor)
• renovate pour gérer les dépendances de façon immutable
• semantic-release pour gérer les releases (tags et artefacts)
• Un contributing standard
• Un dockerignore qui vide le contexte de Docker car on utilise ansible pour construire les containers
• Un gitlab-ci.yml temporaire, le temps qu’on migre vers concourse-ci
• Un test d’upgrade_path fait avec Cucumber
• Un prepare.sh qui génère les binaires et les transmet entre les étapes
• Un docker-compose d’exemple (autonome, sécurisé)
• Des environnements de dev locaux basés sur docker-compose et déclenchables à partir de VSCodium dont un déclencheur qui nettoie complètement l’environnement

Pour cela, il est nécessaire de réussir à compiler les binaires de Goharbor sans passer par une succession de containers Go afin d’extraire des binaires adaptés à notre OS (Ubuntu).

Dans un premier temps, on va faire du DinD (Docker in Docker) et utiliser leur flag de compilation tel quel, c’est à dire en appelant un container GO distant.

Mais ce n’est pas une solution durable car cela oblige à conserver Docker dans l’infrastructure ce qui est contraire à l’un des buts du projet global. On veut, en effet, se débarrasser de Docker au profit de podman/buildah.

Pour référence :

Compile binaries without docker · Issue #13885 · goharbor/harbor

Les dépendances externes seront traitées dans des projets séparés (Clair, Notary,…). Ceci afin d’augmenter la réutilisabilité des portions de l’infrastructure.

Notamment, les bases de données comme Redis ou PostgreSQL n’ont pas d’intérêt à être conçues uniquement pour l’usage de GoHarbor.