Journal de bord 04 janvier 2021

Tout d’abord bonne année.

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.