Bonjour, Habr! Je m'appelle Artyom Zheltak , je suis chef d'équipe et également professeur au cours «Golang Developer» à OTUS. En prévision du début d'un nouveau volet du cours , je souhaite partager mon article avec vous.
Je crois que Golang est génial, mais il y a encore beaucoup de projets php et autres travaillant sur VPS, VDS dans le monde. Vous pouvez y mettre un docker, mais cela (selon l'auteur) est une re-complication de la tâche. Vous pouvez compiler un fichier et le télécharger via FTP - ce n'est pas sûr et pas le feng shui, SFTP est plus sûr, mais ne recommencez pas le feng shui. Automatisons ensuite ce processus via
CircleCI . Nous allons écrire le fichier de configuration pour CI étape par étape, à la fin, nous collecterons le résultat et exécuterons le déploiement.
Exigences de mise en œuvre
- Innovations de serveur minimales
- Le déploiement doit être automatisé
- Le point d'entrée pour le déploiement est le balisage pour l'assembly dev et une confirmation manuelle supplémentaire pour prod
- L'assemblage doit réussir les tests automatiques
- Version du mécanisme de restauration manuelle
Pourquoi CircleCI?
Dès le début, le projet a utilisé un référentiel bitbucket privé. (Désormais, les référentiels privés sont déjà dans le github.) Sans quitter l'écosystème, Atlasian a décidé de prendre CircleCI (ci-après CI). J'ai aimé ça:
- réglage minimum
- fonction de débogage ssh
- version gratuite mais avec des limitations
- 2500 crédits / par semaine (environ 250 minutes de réalisation) #go est collecté et déployé rapidement, nous en avons assez
- exécution à un seul thread # nous n'avons pas beaucoup de projets pour animaux de compagnie
- seulement linux et windows # nous avons besoin de linux
Première partie, flux de travail
Créez un dossier .circle et créez-y un fichier config.yml et décrivez-y le flux de travail attendu (l'ordre d'exécution des tâches)
workflows: version: 2 tagged-build: jobs: - test - dev_deploy: requires: - test - approve_master_deploy: type: approval requires: - test - dev_deploy - prod_deploy: requires: - dev_deploy - approve_master_deploy
Voici le résultat:
Nous avons décrit un modèle selon lequel chaque commit sera d'abord vérifié par des tests, puis déployé en dev, puis, avec confirmation manuelle, envoyé au serveur de combat. Pour guider la brillance, ajoutez un filtre afin que la tâche ne fonctionne que par balise.
- dev_deploy: requires: - test filters: branches: ignore: /.*/ tags: only: /.*/
La deuxième étape, la plus simple
Commençons par exécuter les tests, il y aura un minimum de code.
jobs: test: docker: - image: circleci/golang:1.12 working_directory: ~/go-example/ steps: - checkout # linter' - run: go test -cover -v ./...
Une fois que notre code a été testé et passé les vérifications de style de code, vous pouvez effectuer le déploiement sur dev. Je suggère d'utiliser le superviseur (ver 3.1.4 au moment de la rédaction) pour démarrer le service go, nous collecterons des journaux pour eux.
Ajoutez le fichier supervisor_ph.conf au dossier .circleci, dans CI PH_NAME, il changera en nom de projet. Et dans le même fichier, nous écrirons la sortie des journaux.
[program:PH_NAME] stopasgroup=true user=deploy-user autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PH_NAME.log stderr_logfile=/var/log/supervisor/PH_NAME.log redirect_stderr=true
Tout ce qui distingue notre projet des autres:
Déployer le temps
Pour dev et prod, seuls les serveurs sont modifiés et un suffixe est ajouté au nom de l'application. La configuration est stockée dans des variables d'environnement. (
12 applications factorielles ) Nous retirerons cette partie de l'environnement, nous dupliquerons le reste.
prod_deploy: environment: TARGET_IP: 0.0.0.0 TARGET_DIR: /var/www/deploy-user/go-example REMOTE_USER: deploy-user SERVICE_NAME: go_example_prod docker: - image: circleci/golang:1.12 working_directory: ~/go-example/ steps: - checkout - add_ssh_keys # ci , - run: go build -ldflags "-X main.version=$CIRCLE_TAG" -o ./main ./src/main - run: ssh -o "StrictHostKeyChecking=no" $REMOTE_USER@$TARGET_IP "mkdir $TARGET_DIR/v$CIRCLE_TAG" # , - run: scp main $REMOTE_USER@$TARGET_IP:$TARGET_DIR/v$CIRCLE_TAG/ # - run: sed "s/PH_NAME/$SERVICE_NAME/g" .circleci/supervisor_ph.conf > .circleci/$SERVICE_NAME.conf - run: echo command=$TARGET_DIR/v$CIRCLE_TAG/main >> .circleci/$SERVICE_NAME.conf - run: scp .circleci/$SERVICE_NAME.conf $REMOTE_USER@$TARGET_IP:$TARGET_DIR/v$CIRCLE_TAG/ - run: ssh $REMOTE_USER@$TARGET_IP "ln -sf $TARGET_DIR/v$CIRCLE_TAG/$SERVICE_NAME.conf /etc/supervisord.d" - run: ssh $REMOTE_USER@$TARGET_IP "supervisorctl -c /etc/supervisord.conf reread && supervisorctl -c /etc/supervisord.conf update" - run: curl "$TELEGRAM_SERVICE?msg=$SERVICE_NAME%20v$CIRCLE_TAG%20deployed&channel=go_deploy"
Pour les notifications, nous utilisons notre propre bot, appelé via curl. La commande `when: on_fail` fonctionne en cas de problème, elle peut également être utilisée pour annuler les modifications. Bien que nous ayons un bot télégramme, mais en général, vous pouvez vous en passer et utiliser les notifications standard: Slack, IRC. De plus, les notifications d'erreur sont envoyées au courrier électronique.
La variable `$ TELEGRAM_SERVICE` est ajoutée via la section BUILD SETTINGS → Variables d'environnement.
- run: command: curl "$TELEGRAM_SERVICE?msg=$SERVICE_NAME%20v$CIRCLE_TAG%20failed&channel=go_deploy" when: on_fail
Ligne d'arrivée
Nous poussons dans github ou dans bitbucket. Après, nous allons à CircleCI dans l'élément Ajouter un projet
Sélectionnez ensuite Commencer la construction. La dernière étape consistera à ajouter une clé ssh pour l'autorisation sur le serveur sous l'utilisateur sélectionné.
Tout peut se faire déployer, mettre une balise et commencer à profiter de la vie. La version finale ./.circleci/config.yml -
ici