Hallo habr Mein Name ist Artyom Zheltak , ich bin ein Teamleiter und auch ein Lehrer beim „Golang Developer“ -Kurs bei OTUS. Im Vorgriff auf den Start eines neuen Streams des Kurses möchte ich meinen Artikel mit Ihnen teilen.
Ich glaube, dass Golang großartig ist, aber es gibt immer noch viele PHP- und andere Projekte auf der Welt, die an VPS, VDS arbeiten. Sie können dort einen Docker platzieren, aber dies ist (laut Autor) eine erneute Komplikation der Aufgabe. Sie können eine Datei zusammenstellen und über FTP hochladen - es ist unsicher und kein Feng Shui, SFTP ist sicherer, aber kein Feng Shui mehr. Dann lassen Sie uns diesen Prozess über
CircleCI automatisieren. Wir werden die Konfigurationsdatei für CI Schritt für Schritt schreiben, am Ende werden wir das Ergebnis sammeln und das Deployment ausführen.
Implementierungsanforderungen
- Minimale Serverinnovationen
- Deploy muss automatisiert sein
- Der Einstiegspunkt für die Bereitstellung ist das Markieren der Dev-Assembly und die zusätzliche manuelle Bestätigung für prod
- Die Montage muss die automatische Prüfung bestehen
- Version mit manuellem Rollback-Mechanismus
Warum CircleCI?
Das Projekt verwendete von Anfang an ein privates Bitbucket-Repository. (Jetzt befinden sich private Repositories bereits im Github.) Ohne das Ökosystem zu verlassen, entschied sich Atlasian für CircleCI (im Folgenden: CI). Das hat mir gefallen:
- Mindesteinstellung
- SSH-Debug-Funktion
- kostenlose Version, aber mit Einschränkungen
- 2500 Credits / Woche (ca. 250 Minuten nach Fertigstellung) #go wird schnell gesammelt und bereitgestellt, wir haben genug
- Single-Thread-Ausführung # Wir haben nicht viele Pet-Projekte
- Nur Linux und Windows # Wir brauchen Linux
Teil Eins, Workflow
Erstellen Sie einen Ordner .circle und erstellen Sie eine config.yml-Datei darin und beschreiben Sie dort den erwarteten Workflow (die Reihenfolge der Taskausführung).
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
Hier ist das Ergebnis:
Wir haben ein Muster beschrieben, nach dem jedes Commit zuerst durch Tests überprüft, dann an dev weitergeleitet und dann mit manueller Bestätigung an den Kampfserver gesendet wird. Um den Glanz zu steuern, fügen Sie einen Filter hinzu, damit die Aufgabe nur nach Tag funktioniert.
- dev_deploy: requires: - test filters: branches: ignore: /.*/ tags: only: /.*/
Der zweite Schritt, der einfachste
Beginnen wir mit den Tests, es wird ein Minimum an Code geben.
jobs: test: docker: - image: circleci/golang:1.12 working_directory: ~/go-example/ steps: - checkout # linter' - run: go test -cover -v ./...
Nachdem unser Code getestet und die Codestilprüfungen bestanden wurde, können Sie ihn auf dev bereitstellen. Ich schlage vor, Supervisor (Version 3.1.4 zum Zeitpunkt des Schreibens) zu verwenden, um den Go-Service zu starten. Wir sammeln Protokolle für sie.
Fügen Sie die Datei supervisor_ph.conf zum Ordner .circleci hinzu. In CI PH_NAME wird der Name des Projekts geändert. Und in dieselbe Datei schreiben wir die Ausgabe der Protokolle.
[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
All das unterscheidet unser Projekt von anderen:
Zeit bereitstellen
Für dev und prod werden nur die Server geändert und dem Anwendungsnamen ein Suffix hinzugefügt. Die Konfiguration wird in Umgebungsvariablen gespeichert. (
12-Faktor-Anwendungen ) Wir werden diesen Teil an die Umwelt abgeben, wir werden den Rest duplizieren.
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"
Für Benachrichtigungen verwenden wir unseren eigenen Bot, der durch Curl aufgerufen wird. Der Befehl "when: on_fail" funktioniert, wenn ein Fehler aufgetreten ist. Er kann auch zum Zurücksetzen von Änderungen verwendet werden. Wir haben zwar einen Telegramm-Bot, aber im Allgemeinen kann man darauf verzichten und Standardbenachrichtigungen verwenden: Slack, IRC. Plus-Fehlermeldungen gehen an E-Mail.
Die Variable "$ TELEGRAM_SERVICE" wird im Abschnitt EINSTELLUNGEN ERSTELLEN → Umgebungsvariablen hinzugefügt.
- run: command: curl "$TELEGRAM_SERVICE?msg=$SERVICE_NAME%20v$CIRCLE_TAG%20failed&channel=go_deploy" when: on_fail
Ziellinie
Wir schieben in Github oder in Bitbucket. Nachdem wir zu CircleCI im Punkt Projekt hinzufügen gegangen sind
Wählen Sie dann Start building. Der letzte Schritt ist das Hinzufügen eines SSH-Schlüssels für die Autorisierung auf dem Server unter dem ausgewählten Benutzer.
Alles kann bereitgestellt werden, ein Tag setzen und das Leben genießen. Die endgültige Version ./.circleci/config.yml -
hier