Auto-build Docker cassée

[thbar]

J'ai créé une nouvelle release avec un tag associé.

Je ne la vois pas apparaître sur le Hub Docker.

Est-ce que quelqu'un peut m'ajouter à la bonne team pour avoir accès au débuggage de la build ?

[thbar]

Ok après avoir jeté un premier coup d'oeil et obtenu les accès Docker Hub sur cette image, j'ai les logs suivants:

Cloning into '.'...
Warning: Permanently added the RSA host key for IP address '140.82.112.4' to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
please ensure the correct public key is added to the list of trusted keys for this repository (128)

Je regarderai jeudi.

[thbar]

Après enquête c'est assez compliqué: l'image transport est actuellement attachée à l'organisation betagouv, et le "linked account" pour toute l'organisation appartient à une personne physique, qui n'est en fait pas au courant de ce point (pour en avoir discuté avec la personne concernée, que je floute ici pour des raisons de sécurité ops):

https://hub.docker.com/orgs/betagouv/settings/linked-accounts

Je ne connais pas encore bien cette partie, mais il semblerait qu'il faille que ce user soit rattaché partiellement niveaux droits à notre repository transport-ops, ce qui ne va pas dans le sens du courant.

J'ai créé après discussion avec mon équipe une organisation dédiée:

https://hub.docker.com/u/transportdatagouv

Toutefois pour l'instant la création de repository est physiquement impossible, on ne peut pas sélectionner l'organisation dans la dropdown:

J'ai réussi à voir le choix une fois, je pense qu'il y a un bug chez Docker (eventual inconsistency), je vais réessayer.

[thbar]

J'ai trouvé... c'est... hum.

https://twitter.com/thibaut_barrere/status/1335907349354176512

[thbar]

Le repository est créé:

https://hub.docker.com/r/transportdatagouv/transport-site

Etapes suivantes:

• Créer un "service user" dédié https://docs.docker.com/docker-hub/builds/#autobuild-for-teams
• Voir où on stocke le mot de passe associé (au pire il sera dans ma vault et je partagerai manuellement s'il n'existe pas d'infrastructure commune là dessus)
• Remettre en place la build
• Livrer une nouvelle image
• Utiliser la nouvelle image sur les tests Mise à jour Elixir, Erlang & NodeJS transport-site#1363
• Utiliser la nouvelle image en staging puis production

[thbar]

Je me suis inspiré de service users for team auto builds qui est le mode opératoire recommandé.

J'ai créé un user spécifique (aka "service user").

La création de cet user est autorisé (voir "machine account" dans les ToS de GitHub) mais a donné lieu à un compte "flagged" et a nécessité un échange avec le support:

A machine account is an Account set up by an individual human who accepts the Terms on behalf of the Account, provides a valid email address, and is responsible for its actions. A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions. You may maintain no more than one free machine account in addition to your free User Account.

Je me suis loggé en tant que cet utilisateur dans une session navigateur séparé.

Je me suis ensuite loggé sur hub.docker.com en tant que moi-même (owner), puis il apparaît l'écran suivant quand je clique sur "builds":

Je clique sur "Link to GitHub", puis apparaît l'écran suivant:

Je clique sur "connect" pour GitHub.

⚠️ Attention je vérifie que ce n'est pas mon compte personnel qui apparaît, mais bien le compte service, pour ne pas partager mes repositories private avec Docker Hub alors qu'il n'y en a pas le besoin.

Je dois obtenir l'écran suivant:

On doit obtenir l'écran suivant:

Je sauve et j'ajouterai la suite, car c'est pas terminé.

Voir en teaser: docker/hub-feedback#1943

[thbar]

En pratique c'est compliqué (voir l'issue hub-feedback).

Je vais étudier la possibilité d'activer le GitHub container registry:

https://docs.github.com/en/free-pro-team@latest/packages/getting-started-with-github-container-registry

[thbar]

Je mets de côté pour gagner un peu de temps : on va builder pour l'instant en manuel et en local, et pusher vers Docker Hub.

À terme on remettra en place des auto-builds, ou bien chez Docker, ou bien via une GitHub Action.

[thbar]

Evidemment il convient de reconstruire régulièrement l'image et de la re-pusher (après test), car sans cela, les patchs de sécurité ne sont pas inclus (voir https://snyk.io/blog/take-actions-to-improve-security-in-your-docker-images/).

[thbar]

Il sera impératif de remettre en place des builds, probablement avec la GitHub Action suivante:

https://github.com/marketplace/actions/build-and-push-docker-images

[thbar]

Lien intéressant quand on attaquera ce sujet à nouveau:

https://evilmartians.com/chronicles/build-images-on-github-actions-with-docker-layer-caching

[thbar]

Je vais récréer un ticket "propre". Je pense qu'il sera plus profitable de créer une nouvelle build avec GitHub action, bien testée, que de chercher à corriger ces problèmes sur une grosse orga docker.