ADD: deploy when commit to develop
Merge request reports
Activity
added CI label
enabled an automatic merge when the pipeline for 17fdf6bf succeeds
By Cresson Remi on 2022-05-10T15:19:59 (imported from GitLab)
@remi.cresson par rapport au cache bazel, ça semble normal que tu ne puisses pas accéder à un bazel-remote cache via local host dans un dind (et as-tu moyen de lancer le daemon bazel sur l'host de ce runner ?)
L'idéal serait de déployer le bazel-cache sur une URL dédiée d'où tu pourrais pull le cache sans soucis de config réseau...By Vincent Delbar on 2022-05-10T16:42:12 (imported from GitLab)
Edited by Cresson Remimentioned in commit 5701c2ab
By Cresson Remi on 2022-05-10T16:36:33 (imported from GitLab)
ouai, j'ai essayé par tous les moyens d'utiliser une instance de bazel-cache externe qui tourne sur localhost:9090 mais malheureusement, je n'arrive pas à m'y connecter depuis un dind. le principal problème ce n'est pas le cache bazel, mais le fait que le multistage-build rend compliqué la ré-utilisation du cache. Là en l'état c'est mieux qu'avant, mais il ne le réutilise pas systématiquement j'ai remarqué (par ex. quand tu crée une nouvelle MR)
By Cresson Remi on 2022-05-10T16:51:20 (imported from GitLab)
Pour moi c'est quand même plutôt un problème, parce que là où tu pourrais avoir un cache unifié avec des builds TF propres, tu te retrouves avec des morceaux de caches un peu partout dans des layers docker et ça semble galère à gérer (en plus j'ai remarqué avec scenes que le cache gitlab semble un peu instable)
By Vincent Delbar on 2022-05-10T16:55:09 (imported from GitLab)
c'est sûr que si j'arrivais à utiliser ce fichu localhost:9090 ça ferait des builds beaucoup plus rapides si on touche aux deux premiers stages (otbtf-base et builder).
Mais en principe si on y touche pas, on ne rebuild pas ces deux stages là (la preuve: la MR que je viens de faire!)
By Cresson Remi on 2022-05-10T16:57:14 (imported from GitLab)
Ce que je comprends pas c'est comment tu lance le docker du bazel remote cache ? Tu as un accès au host du runner ?
Je vois pas comment tu peux avoir les deux sur un même host.
Mais là concrètement si je comprends bien tu build une baseCACHE_IMAGE_BASEet tu prends le cache là dedans ? C'est un cache au niveau de docker, pas de gitlab comme j'ai testé dans scenes ?By Vincent Delbar on 2022-05-10T17:26:51 (imported from GitLab)
ha ok ! mais le truc du socket ça marche que pour les commandes docker, pas pour le network il me semble.
mais donc si tu as la main sur le host, ça doit être faisable si l'image docker bazel cache est lancée également dans le dind, elle serait donc accessible via network bridge (en supprimant network mode host, tu aurai accès aux autres images du stack docker de la CI, avec le nom du conteneur comme hostname).
et donc tu aurais plus qu'a monter un volume dans le docker bazel avec tout le cache pour le rendre persistant (comme on fait sur le host initialement).By Vincent Delbar on 2022-05-10T21:42:12 (imported from GitLab)
Edited by Cresson RemiOui. Et comme c'est du docker, c'est normalement possible d'ajouter un service qui est un process docker simple qui écoute un port (comme le serveur bazel cache) et qui est accessible au conteneur qui build cad le conteneur dans le conteneur aka le dind. Donc j'ai dit de la merde au dessus, dans ce cas là c'est pas dans le dind mais au même niveau. D'ailleurs c'est peut-être la première raison d'être de cette image docker bazel cache.
Là ou je suis pas du tout sûr de mon coup, c'est comment tu gère les volumes entre le host, le docker et le dind, mais j'imagine dans la config du runner pour le premier niveau. Par contre pour passer le volume au niveau du service bazel cache aucune idée mais ça doit être possible.
Mais c'est possiblement faisable aussi de lancer le bazel cache dans le dind (avec l'option -d, juste avant les docker build, comme tu le ferai en temps normal sur ton host).
By Vincent Delbar on 2022-05-10T23:34:24 (imported from GitLab)
Edited by Cresson RemiBon en fait les volumes par job ou services c'est pas implémenté pour le moment.
Ça semble donc difficile de monter un volume 2 fois. Possible que au niveau du runner.
A voir si lancer une commande docker run -d avant les docker build ça fonctionne (ou tu as déjà testé ?) j'image que ça pose un soucis de ports.By Vincent Delbar on 2022-05-11T01:40:39 (imported from GitLab)
Edited by Cresson RemiDonc le plus simple reste de lancer le docker bazel direct depuis le host, donc en dehors du dind ou du runner. Mais ça ne marche pas avec le network mode host. Est-ce que tu as bien ajouté cette option là aussi dans la config du runner, pas juste dans l'option des commmandes docker build ?
Il faut surement utiliser l'adresse ip de l'interface docker0 à la place ou ajouter l'option --add-host pour avoir un hostname.
Tout est décrit ici.
https://stackoverflow.com/questions/31324981/how-to-access-host-port-from-docker-container
Sans la dind et en trouvant le bonne config network du runner, en passant une IP ou le bon hostname, il doit y avoir moyen (aussi possiblement quelques config firewall nécessaires).By Vincent Delbar on 2022-05-11T01:33:28 (imported from GitLab)
Edited by Cresson Remi
ça doit être possible si tu montes le volume du cache bazel 2 fois (dans le docker host puis dans le dind, je ne pense pas que Docker empêche ça)
By Vincent Delbar on 2022-05-10T21:40:51 (imported from GitLab)
Edited by Cresson RemiÇa peut venir du fait de réutiliser le docker host dans le dind. Ce qui explique aussi les warnings concernant le socket etc. Dind c'est pas censé être utilisé de cette manière en lui donnant accès au docker host. C'est justement prévu pour l'isolation. Un docker qui execute un process docker.
Là ce que tu fais c'est donner au dind le contrôle du host. Ce n'est plus le dind qui build mais bien le host. C'est pratique quand tu as vraiment besoin d'un accès au host, surement pour des histoires de data / de cache.
Mais normalement pas nécessaire, si tu as juste à pousser dans un repo distant. Et même si tu dois pousser sur un repo local, qui n'a pas d'url publique, ça doit être possible avec la bonne config réseau.Edit : non oui maintenant je me souviens du soucis, on peut pas monter un volume dans une commande build, c'est justement pour ça que j'avais trouvé le truc de bazel remote cache !
By Vincent Delbar on 2022-05-11T01:37:41 (imported from GitLab)
Edited by Cresson RemiSinon peut-être des explications ici https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41227.
By Vincent Delbar on 2022-05-10T23:14:49 (imported from GitLab)
Edited by Cresson RemiCette issue est référencé dans la doc ainsi :
Because the docker:19.03.12-dind container and the runner container don’t share their root file system, you can use the job’s working directory as a mount point for child containers. For example, if you have files you want to share with a child container, you might create a subdirectory under /builds/$CI_PROJECT_PATH and use it as your mount point. For a more detailed explanation, view issue #41227.
By Vincent Delbar on 2022-05-10T23:29:40 (imported from GitLab)
Edited by Cresson RemiAprès vérif dans la doc gitlab, j'avoue que c'est très confus. Mais ils suggèrent que tu build des image soit grâce à dind, soit en partageant ton socket... là tu fais les deux ! Plus bas ils parlent de cas ou tu as besoin du dind + socket mais c'est des cas particulier (mirror registry). On peut aussi y lire
If you bind the Docker socket and you are using GitLab Runner 11.11 or later, you can no longer use docker:19.03.12-dind as a service. Volume bindings are done to the services as well, making these incompatible.
L'idéal serait d'éviter dind. Normalement un runner docker executor + socket bind, ce conteneur docker peut aussi lancer un service bazel cache (a la place de dind) si c'est possible en termes de volumes - sinon qui lance une commande docker run -d grâce à la quelle tu re-montes ton volume du runner dans le conteneur bazel, ce serait le top parce que tu caches les layers et images docker direct dans le host + un volume pour cache bazel.
By Vincent Delbar on 2022-05-11T00:27:57 (imported from GitLab)
Edited by Cresson Remi
As-tu vu les warning en début de la task CI ? https://gitlab.irstea.fr/remi.cresson/otbtf/-/jobs/256095/raw
By Vincent Delbar on 2022-05-10T21:39:35 (imported from GitLab)
Du coup ref à mon commentaire au dessus sur le fait de filer le docker host au dind. Je pense pas que ça explique le soucis des volumes mount (à vérifier), par contre je crois que ça explique ces warnings, et aussi peut-être les trucs étranges que tu as pu voir dans le caching.
Si c'est ton host qui cache les builds et pas le conteneur dind de la CI, ça doit être un sacré bazar tous ces layers.
Fais gaffe de surveiller la taille de ton /var/lib/docker, parce que tes manips de cache et de root image que tu pousses sur le host pour rebuild cached from, etc.... quelle affaire !
A mon avis ce serait préférable de faire que du bazel cache, et du gitlab cache comme testé dans scenes, là aussi c'est normalement possible de cacher à travers branche et/ou tout le repo...
Et je crois avoir vu en regardant les logs que, étant donné que tu build toutes les images d'affilé en fin du yaml, dans le même job, docker utilise naturellement le cache des builds précédant quand il peux comme par exemple quand la seule chose qui change c'est KEEP_SRC_OTB. De la même manière que si tu le lances sur ton host.
Mais là c'est les layers en cache du dind. Sauf que dans ton cas tu lui passes le host. Donc oui ça permet d'avoir ton cache docker persistent d'un build à l'autre mais bon... pas nécessaire ce mille-feuille dans le cas où on arrive à faire marcher le cache bazel. Ça ne me semble pas utile dans ton cas vu que tu as prends justement la peine de push des images dont tu veux cache from...By Vincent Delbar on 2022-05-10T23:43:41 (imported from GitLab)
Edited by Cresson RemiAussi ces histoires de push pull entre l'instance gitlab registry et ton runner tu perds surement beaucoup de temps dans le réseau. Dans l'idéal (même sans parler du cache bazel), avecles layers du docker host + le gitlab cache et les artefacts, c'est ton runner qui cache déjà tout localement ! Un tag / layer que tu as build sur le host est tout de suite dispo pour cache from, pas besoin de tag & push
By Vincent Delbar on 2022-05-11T00:35:50 (imported from GitLab)
Edited by Cresson Remi
Un option peut-être qui pourrait tout simplifier serait l'approche que j'ai implémenté pour Moringa, au lieu du multistage build.
Un dockerfile qui fait la base, et ça tu le pousses et tu le gardes longtemps (parce que tu changes rarement de version TF). On arrive peut-être à automatiser ça dans la CI avec le cache bazel, mais ça peut être une tâche planifiée ou lancée manuellement, pas à chaque commit. Si compliqué avec la CI ça peut aussi être fait à la mano et là tu peux facilement utiliser le bazel cache comme tu faisais jusqu'à maintenant.Avec ça tu produis toutes les bases nécessaires TF pour tes différentes images (cpu, gpu, AVX2, AVX512, etc...).
La CI lancerait des build OTB à partir de ces bases ubuntu-tf, avec un deuxième Dockerfile.
Plus de soucis cache from parce que tu pars d'une image propre et stockée dans le registry.
Ça règle le problème de push & pull parce que tu ne pull que quand nécessaire et ces images bases resteront de toute manière dans le cache de ton host docker godzilla. Et ça évite d'exploser la taille de ton instance docker, en arrêtant de pousser une base pour chaque branche, comme ce que tu fais actuellement : puisque cette base est toujours la même (enfin seule TF varie), pas besoin d'en avoir une par branche ou MR.
Tu as toujours les layers des builds précédents qui seront automatiquement réutilisés par builder vu que tu lui passes le socket docker host que tu tu build tout dans le même job.
Ce serait même possible d'avoir plusieurs jobs en parallèle, pour tout ceux qui ont la même base TF (un job qui fait cpu + cpu-dev, un qui fait gpu, gpu-dev, etc.).Enfin ça permettrait aux utilisateurs de build leur propre docker otbtf à partir de nos bases ubuntu-tf déjà dispo. Ce serait donc bien plus rapide pour eux aussi.
By Vincent Delbar on 2022-05-11T10:32:55 (imported from GitLab)
Edited by Cresson Remi
