J'essaie d'étendre l'une de mes tâches CI sur GitLab:
deploy-stage:
image: python:3.5
environment: stage
script:
- pip install awscli
- aws s3 cp dist s3://$S3_BUCKET_STAGE/ --recursive
only:
- stage
Ce que je veux, c'est pouvoir créer du code à partir de fichiers Vue.js (en utilisant npm run build ), mais pour ce faire, j'ai besoin de Node.js. Mais j'ai également besoin de Python pour pouvoir télécharger des fichiers sur S3. Comment puis-je y parvenir?
3 Réponses :
Je suggérerais les approches suivantes:
Tout d'abord, simple. Utilisez un conteneur à usage général comme image de base, disons ubuntu et installez à la fois python et npm ici.
Pourquoi ne pas utiliser l'image python et l'installer npm ou vice versa:
votre gestionnaire de paquets ( apt / apk ) devient implicite sauf si vous spécifiez python: 3-alpine ou autre. Personnellement, je préfère une définition explicite parce que vos coéquipiers seraient confondus avec la question "Quel est le responsable de l'image npm?" s'ils ne le connaissent pas.
l'ensemble des packages préinstallés est également indéfini et peut changer de version en version. bash existe-t-il dans python: 3 ?
changer la version d'un outil (disons python2 -> python3 ) pourrait considérablement influencer l'image si elle est utilisée comme base pour tous les autres.
demain, vous devrez ajouter le troisième outil ( gcc ?) à votre image.
Donc, avoir une image de base à usage général avec tous les outils nécessaires installés me semble explicitement être une meilleure idée.
Notez également que vous devrez probablement séparer votre processus de création d'image de l'utilisation de cette image. Je préfère avoir la première étape de préparer dans mon CI gitlab qui construit toutes les images nécessaires et les met dans le registre de docker privé GitLab.
C'est intéressant. Puis-je créer cette image de base à usage général en utilisant uniquement GitLab CI ou je devrai d'abord en préparer une localement, puis la télécharger dans le registre Docker privé? Je suis un débutant en ce qui concerne Docker
Bien sûr, vous pouvez le construire avec gitlab. Utilisez le service docker: dind et docker: latest en tant que générateur
Vous devez connecter docker: dind en tant que service partagé et créer une nouvelle tâche (à l'étape prepare ), basée sur docker: latest ou docker: image stable (par exemple). Dans votre travail, vous pouvez appeler docker CLI tandis que le service fournira un démon
Que dois-je lire pour bien comprendre ces choses? Je ne saisis pas encore complètement l'idée et je veux :)
digitalocean.com/community/tutorials/... medium.com/@tonywooster/...
Une autre question: puis-je intégrer une tâche et pousser vers AWS dans une autre? Et puis créer des pipelines séparés pour les déploiements de staging et production ?
Lorsque vous créez une image, vous obtenez un artefact (fichier image) - vous devez le pousser dans un registre. à une autre étape, vous pouvez le pousser vers AWS à partir du registre, mais franchement, je n'ai jamais travaillé avec AWS et pas un expert ici
Vous pouvez simplement utiliser 2 étapes de construction séparées et utiliser des artefacts pour passer la construction entre les étapes.
Ce que vous pouvez faire est dans votre première étape de construction, vous utilisez une image avec vue.js et exécutez npm run build et toutes les autres étapes que vous devez effectuer.
À la fin du travail, vous spécifiez artefacts .
image: node:alpine
before_script:
- yum install curl -y && yum update -y
script:
- npm run build
Cela passerait la construction du dossier à la tâche suivante.
Ensuite, vous pouvez exécuter votre deuxième tâche en utilisant python pour télécharger le contenu vers S3.
Cela vous donne la liberté de construire votre programme comme vous le souhaitez sans avoir à vous limiter à un environnement spécifique.
Si vous ne trouvez pas une image qui fait ce dont vous avez besoin vous pouvez créer le vôtre ou, si le temps de construction n'est pas important, vous pouvez utiliser une image de base et installer tout ce dont vous avez besoin dans le cadre de votre travail.
artifacts:
paths:
- build
Ce qui précède snippet installerait curl sur une image alpine de nœud.
Oui, cela semble plus facile à faire. Je vais y plonger - j'ai récemment lu que je devais également définir expire pour les artefacts afin qu'ils ne restent pas là pour toujours: PI pense que je vais créer une image pour le nœud puis npm run build < / code> puis passez au deuxième travail avec python et aws
Ah oui. Si c'est un projet fluide, j'ai tendance à conserver les artefacts pendant 1 semaine. Si aucun problème n'est survenu d'ici là, tout va bien. Dans le pire des cas, vous pouvez toujours simplement réexécuter le pipeline à partir de la validation pour recréer l'artefact si vous en avez besoin.
Après un peu d'aide d'ici, je me suis retrouvé avec une telle configuration gitlab-ci.yml :
build-stage:
stage: build
image: node:latest
environment:
name: stage
script:
- npm install
- npm run build-stage
only:
- stage
artifacts:
expire_in: 2 hrs
paths:
- dist/
deploy-stage:
stage: deploy
image: python:3.5
environment:
name: stage
script:
- pip install awscli
- aws s3 cp dist s3://$S3_BUCKET_STAGE/ --recursive
dependencies:
- build-stage
only:
- stage
C'est facile et lisible. Pas besoin d'images personnalisées de Docker - effectuez simplement une tâche, puis déplacez les résultats vers la tâche suivante. Fonctionne comme un charme.