Een CI/CD-keten creëren en het werk automatiseren met Docker

Eind jaren negentig schreef ik mijn eerste websites. Destijds was het heel eenvoudig om ze in werkende staat te brengen. Er was een Apache-server op een gedeelde hosting, je kon via FTP inloggen op deze server door zoiets te schrijven als ftp://ftp.example.com. Vervolgens moest u uw naam en wachtwoord invoeren en de bestanden naar de server uploaden. Er waren andere tijden, alles was toen eenvoudiger dan nu.

In de twintig jaar daarna is alles enorm veranderd. Websites zijn complexer geworden; ze moeten worden samengesteld voordat ze in productie worden genomen. Eén enkele server werd een groot aantal servers die achter load balancers draaiden, en het gebruik van versiebeheersystemen werd gemeengoed.

Voor mijn persoonlijke project had ik een speciale configuratie. En ik wist dat ik de mogelijkheid nodig had om de site in productie te nemen door slechts één actie uit te voeren: code naar een filiaal schrijven master op GitHub. Bovendien wist ik dat ik, om de werking van mijn kleine webapplicatie te garanderen, geen enorm Kubernetes-cluster wilde beheren, of Docker Swarm-technologie wilde gebruiken, of een vloot van servers met pods, agents en allerlei andere wilde onderhouden. complexiteiten. Om het doel te bereiken om het werk zo gemakkelijk mogelijk te maken, moest ik vertrouwd raken met CI/CD.

Als u een klein project heeft (in dit geval een Node.js-project) en u wilt weten hoe u de implementatie van dit project kunt automatiseren, terwijl u ervoor zorgt dat wat in de repository is opgeslagen precies overeenkomt met wat in de productie werkt, dan kan ik denk dat je misschien geïnteresseerd bent in dit artikel.

Vereisten

Van de lezer van dit artikel wordt verwacht dat hij een basiskennis heeft van de opdrachtregel en het schrijven van Bash-scripts. Bovendien heeft hij accounts nodig Travis CI и Docker-hub.

doelen

Ik zal niet zeggen dat dit artikel onvoorwaardelijk een “tutorial” kan worden genoemd. Dit is meer een document waarin ik vertel wat ik heb geleerd en het proces beschrijf dat bij mij past voor het testen en implementeren van code in productie, uitgevoerd in één geautomatiseerde doorgang.

Dit is wat mijn workflow uiteindelijk werd.

Voor code die naar elke repositorytak is gepost, behalve master, worden de volgende acties uitgevoerd:

• Het project dat voortbouwt op Travis CI gaat van start.
• Alle unit-, integratie- en end-to-end tests worden uitgevoerd.

Alleen voor code die in master, wordt het volgende uitgevoerd:

• Alles wat hierboven is vermeld, plus...
• Het bouwen van een Docker-image op basis van de huidige code, instellingen en omgeving.
• De afbeelding implementeren in Docker Hub.
• Verbinding met de productieserver.
• Een afbeelding uploaden van Docker Hub naar de server.
• De huidige container stoppen en een nieuwe starten op basis van de nieuwe afbeelding.

Als u absoluut niets weet over Docker, afbeeldingen en containers, hoeft u zich geen zorgen te maken. Ik zal je er alles over vertellen.

Wat is CI/CD?

De afkorting CI/CD staat voor ‘continue integratie/continue implementatie’.

▍Continue integratie

Continue integratie is een proces waarbij ontwikkelaars zich committeren aan de belangrijkste broncoderepository van het project (meestal een vertakking master). Tegelijkertijd wordt de kwaliteit van de code gewaarborgd door geautomatiseerd testen.

▍Continue implementatie

Continue implementatie is de frequente, geautomatiseerde implementatie van code in productie. Het tweede deel van het CI/CD-acroniem wordt soms gespeld als ‘continue levering’. Dit is in principe hetzelfde als ‘continue implementatie’, maar ‘continue levering’ impliceert de noodzaak om wijzigingen handmatig te bevestigen voordat het projectimplementatieproces wordt gestart.

Aan de slag

De app waarmee ik dit allemaal leerde heet Maak een notitie. Dit is een webproject waar ik aan werk, ontworpen voor het maken van aantekeningen. In eerste instantie probeerde ik het te doen JAMStack-project, of gewoon een front-end-applicatie zonder server, om te profiteren van de standaard hosting- en projectimplementatiemogelijkheden die het biedt Netlify. Naarmate de complexiteit van de applicatie groeide, moest ik het servergedeelte ervan creëren, wat betekende dat ik mijn eigen strategie moest formuleren voor geautomatiseerde integratie en geautomatiseerde implementatie van het project.

In mijn geval is de applicatie een Express-server die draait in de Node.js-omgeving, die een React-applicatie van één pagina bedient en een beveiligde server-side API ondersteunt. Deze architectuur volgt de strategie die terug te vinden is in gegeven Volledige stack-authenticatiegids.

Ik heb overlegd met vriend, een automatiseringsexpert, en vroeg hem wat ik moest doen om het allemaal te laten werken zoals ik wilde. Hij gaf me het idee hoe een geautomatiseerde workflow eruit zou moeten zien, zoals beschreven in het gedeelte Doelstellingen van dit artikel. Het hebben van deze doelen betekende dat ik moest uitzoeken hoe ik Docker moest gebruiken.

havenarbeider

Docker is een tool waarmee applicaties dankzij containerisatietechnologie eenvoudig kunnen worden gedistribueerd, ingezet en uitgevoerd in dezelfde omgeving, zelfs als het Docker-platform zelf in verschillende omgevingen draait. Eerst moest ik de Docker-opdrachtregelhulpmiddelen (CLI) in handen krijgen. Instructies De Docker installatiehandleiding is niet heel duidelijk en begrijpelijk te noemen, maar je kunt er wel uit leren dat je, om de eerste installatiestap te kunnen zetten, Docker Desktop (voor Mac of Windows) moet downloaden.

Docker Hub is ongeveer hetzelfde als GitHub voor git-opslagplaatsen of register NPM voor JavaScript-pakketten. Dit is een online opslagplaats voor Docker-images. Dit is waar Docker Desktop verbinding mee maakt.

Om met Docker aan de slag te gaan, moet je dus twee dingen doen:

• Ingesteld Docker-bureaublad.
• Registreren voor Docker-hub.

Hierna kunt u controleren of de Docker CLI werkt door de volgende opdracht uit te voeren om de Docker-versie te controleren:

docker -v

Meld u vervolgens aan bij Docker Hub door uw gebruikersnaam en wachtwoord in te voeren wanneer daarom wordt gevraagd:

docker login

Om Docker te gebruiken, moet u de concepten van afbeeldingen en containers begrijpen.

▍Afbeeldingen

Een afbeelding is zoiets als een blauwdruk die instructies bevat voor het in elkaar zetten van de container. Dit is een onveranderlijke momentopname van het bestandssysteem en de instellingen van de applicatie. Ontwikkelaars kunnen eenvoudig afbeeldingen delen.

# Вывод сведений обо всех образах
docker images

Met deze opdracht wordt een tabel uitgevoerd met de volgende header:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Vervolgens zullen we enkele voorbeelden bekijken van commando's in hetzelfde formaat - eerst is er een commando met commentaar, en dan een voorbeeld van wat het kan uitvoeren.

▍Containers

Een container is een uitvoerbaar pakket dat alles bevat wat nodig is om een ​​applicatie uit te voeren. Een applicatie met deze aanpak zal altijd hetzelfde werken, ongeacht de infrastructuur: in een geïsoleerde omgeving en in dezelfde omgeving. Het punt is dat exemplaren van dezelfde afbeelding in verschillende omgevingen worden gelanceerd.

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍Tags

Een tag is een aanduiding van een specifieke versie van een afbeelding.

▍Een korte verwijzing naar Docker-opdrachten

Hier is een overzicht van enkele veelgebruikte Docker-opdrachten.

Team

verband

effect

docker bouwen

image

Een afbeelding maken van een Dockerfile

docker-tag

image

Afbeeldingstags

docker-afbeeldingen

image

Afbeeldingen vermelden

koppelingsrun

Bak

Een container uitvoeren op basis van een afbeelding

docker push

image

Een afbeelding uploaden naar het register

havenarbeider

image

Een afbeelding uit het register laden

koppelaar ps

Bak

Containers vermelden

docker-systeem snoeien

Afbeelding/container

Ongebruikte containers en afbeeldingen verwijderen

▍Dockerbestand

Ik weet hoe ik een productieapplicatie lokaal moet draaien. Ik heb een Webpack-configuratie die is ontworpen om een ​​kant-en-klare React-applicatie te bouwen. Vervolgens heb ik een opdracht die een op Node.js gebaseerde server op de poort start 5000. Het ziet er zo uit:

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

Opgemerkt moet worden dat ik geen voorbeeldtoepassing voor dit materiaal heb. Maar hier is voor experimenten elke eenvoudige Node-applicatie geschikt.

Om de container te kunnen gebruiken, moet u instructies geven aan Docker. Dit gebeurt via een bestand genaamd Dockerfile, gelegen in de hoofdmap van het project. Dit dossier lijkt op het eerste gezicht nogal onbegrijpelijk.

Maar wat het bevat, beschrijft alleen, met speciale commando's, iets dat lijkt op het opzetten van een werkomgeving. Hier zijn enkele van deze opdrachten:

• NU — Met deze opdracht wordt een bestand gestart. Het specificeert de basisimage waarop de container is gebouwd.
• COPY — Bestanden kopiëren van een lokale bron naar een container.
• WERKDIR — Instellen van de werkmap voor de volgende opdrachten.
• VLUCHTEN - Voer opdrachten uit.
• BLOOT — Poortinstellingen.
• INGANGSPUNT — Indicatie van het uit te voeren commando.

Dockerfile zou er ongeveer zo uit kunnen zien:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

Afhankelijk van de basisimage die u kiest, moet u mogelijk extra afhankelijkheden installeren. Feit is dat sommige basisimages (zoals Node Alpine Linux) zijn gemaakt met als doel ze zo compact mogelijk te maken. Als gevolg hiervan hebben ze mogelijk niet de programma's die u verwacht.

▍Het bouwen, taggen en runnen van de container

Lokale montage en lancering van de container is nadat we dat hebben gedaan Dockerfile, de taken zijn vrij eenvoudig. Voordat u de installatiekopie naar Docker Hub pusht, moet u deze lokaal testen.

▍Montage

Eerst moet je verzamelen image, waarbij u een naam en optioneel een tag opgeeft (als er geen tag is opgegeven, wijst het systeem automatisch een tag aan de afbeelding toe latest).

# Сборка образа
docker build -t <image>:<tag> .

Nadat u deze opdracht hebt uitgevoerd, kunt u zien hoe Docker de image bouwt.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

De build kan een paar minuten duren - het hangt allemaal af van hoeveel afhankelijkheden u heeft. Zodra de build is voltooid, kunt u de opdracht uitvoeren docker images en bekijk de beschrijving van uw nieuwe afbeelding.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍Lanceren

Het beeld is gemaakt. Dit betekent dat u er een container op kunt draaien. Omdat ik toegang wil hebben tot de applicatie die in de container draait op localhost:5000, ik, aan de linkerkant van het paar 5000:5000 in de volgende opdracht geïnstalleerd 5000. Aan de rechterkant bevindt zich de containerhaven.

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

Nu de container is gemaakt en actief is, kunt u de opdracht gebruiken docker ps om informatie over deze container te bekijken (of u kunt de opdracht docker ps -a, dat informatie weergeeft over alle containers, niet alleen over actieve containers).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

Als je nu naar het adres gaat localhost:5000 — u ziet een pagina van een actieve applicatie die er precies hetzelfde uitziet als de pagina van een applicatie die in een productieomgeving draait.

▍Tagging en publiceren

Om een ​​van de gemaakte afbeeldingen op de productieserver te kunnen gebruiken, moeten we deze afbeelding kunnen downloaden van Docker Hub. Dit betekent dat u eerst een repository voor het project op Docker Hub moet maken. Hierna hebben we een plek waar we de afbeelding kunnen verzenden. De afbeelding moet worden hernoemd, zodat de naam begint met onze Docker Hub-gebruikersnaam. Dit moet worden gevolgd door de naam van de repository. Elke tag kan aan het einde van de naam worden geplaatst. Hieronder ziet u een voorbeeld van het benoemen van afbeeldingen met dit schema.

Nu kunt u de afbeelding met een nieuwe naam bouwen en de opdracht uitvoeren docker push om het naar de Docker Hub-repository te pushen.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

Als alles goed gaat, is de afbeelding beschikbaar op Docker Hub en kan deze eenvoudig worden geüpload naar de server of worden overgedragen aan andere ontwikkelaars.

Volgende stappen

Inmiddels hebben we geverifieerd dat de applicatie, in de vorm van een Docker-container, lokaal draait. We hebben de container geüpload naar Docker Hub. Dit alles betekent dat we al zeer goede vooruitgang hebben geboekt in de richting van ons doel. Nu moeten we nog twee vragen oplossen:

• Opzetten van een CI-tool voor het testen en implementeren van code.
• De productieserver zo instellen dat deze onze code kan downloaden en uitvoeren.

In ons geval gebruiken we Travis CI. Als server- DitigalOceaan.

Opgemerkt moet worden dat u hier een andere combinatie van diensten kunt gebruiken. In plaats van Travis CI kunt u bijvoorbeeld CircleCI of Github Actions gebruiken. En in plaats van DigitalOcean - AWS of Linode.

We hebben besloten om met Travis CI te gaan werken, en ik heb al iets geconfigureerd in deze service. Daarom zal ik nu kort praten over hoe je het kunt voorbereiden op het werk.

Travis CI

Travis CI is een hulpmiddel voor het testen en implementeren van code. Ik wil niet ingaan op de fijne kneepjes van het opzetten van Travis CI, aangezien elk project uniek is en dit niet veel voordeel zal opleveren. Maar ik zal de basisbeginselen bespreken om u op weg te helpen als u besluit Travis CI te gebruiken. Of u nu Travis CI, CircleCI, Jenkins of iets anders kiest, overal zullen vergelijkbare configuratiemethoden worden gebruikt.

Ga naar om aan de slag te gaan met Travis CI project site en maak een account aan. Integreer Travis CI vervolgens met uw GitHub-account. Bij het instellen van het systeem moet u de repository opgeven waarmee u het werk wilt automatiseren en de toegang daartoe wilt inschakelen. (Ik gebruik GitHub, maar ik ben er zeker van dat Travis CI kan integreren met BitBucket en GitLab en andere soortgelijke diensten).

Elke keer dat Travis CI wordt gestart, wordt de server gestart, waarbij de opdrachten worden uitgevoerd die zijn gespecificeerd in het configuratiebestand, inclusief het implementeren van de overeenkomstige repository-vertakkingen.

▍Taaklevenscyclus

Travis CI-configuratiebestand gebeld .travis.yml en opgeslagen in de hoofdmap van het project, ondersteunt het concept van gebeurtenissen levenscyclus taken. Deze gebeurtenissen worden vermeld in de volgorde waarin ze plaatsvinden:

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍Testen

In het configuratiebestand ga ik de lokale Travis CI-server configureren. Ik selecteerde Knooppunt 12 als taal en vertelde het systeem om de afhankelijkheden te installeren die nodig zijn om Docker te gebruiken.

Alles wat erin staat .travis.yml, zal worden uitgevoerd wanneer alle pull-aanvragen naar alle vertakkingen van de repository worden gedaan, tenzij anders aangegeven. Dit is een nuttige functie omdat het betekent dat we alle code die in de repository binnenkomt, kunnen testen. Hierdoor weet u of de code gereed is om naar de vertakking te worden geschreven. master, en of dit het bouwproces van het project zal doorbreken. In deze globale configuratie installeer ik alles lokaal, voer ik de Webpack-ontwikkelserver op de achtergrond uit (dit is een functie van mijn workflow) en voer ik tests uit.

Als u wilt dat uw repository badges weergeeft die de testdekking aangeven, hier U kunt korte instructies vinden over het gebruik van Jest, Travis CI en Overalls om deze informatie te verzamelen en weer te geven.

Dus hier is de inhoud van het bestand .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

Dit is waar de acties eindigen die worden uitgevoerd voor alle vertakkingen van de repository en voor pull-aanvragen.

▍Implementatie

Op basis van de veronderstelling dat alle geautomatiseerde tests succesvol zijn afgerond, kunnen we, wat optioneel is, de code op de productieserver implementeren. Omdat we dit alleen willen doen voor code uit de branch master, geven we het systeem passende instructies in de implementatie-instellingen. Voordat u de code probeert te gebruiken die we hierna in uw project zullen bekijken, wil ik u waarschuwen dat u een daadwerkelijk script moet hebben dat moet worden geïmplementeerd.

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

Het implementatiescript lost twee problemen op:

• Bouw, tag en stuur de afbeelding naar Docker Hub met behulp van een CI-tool (in ons geval Travis CI).
• Het laden van de afbeelding op de server, het stoppen van de oude container en het starten van een nieuwe (in ons geval draait de server op het DigitalOcean-platform).

Eerst moet u een automatisch proces instellen voor het bouwen, taggen en pushen van de afbeelding naar Docker Hub. Dit lijkt allemaal erg op wat we al handmatig hebben gedaan, behalve dat we een strategie nodig hebben voor het toewijzen van unieke tags aan afbeeldingen en het automatiseren van logins. Ik had problemen met sommige details van het implementatiescript, zoals tagstrategie, inloggen, SSH-sleutelcodering en het tot stand brengen van SSH-verbindingen. Maar gelukkig is mijn vriend heel goed met bash, net als met veel andere dingen. Hij heeft mij geholpen dit script te schrijven.

Het eerste deel van het script uploadt dus de afbeelding naar Docker Hub. Dit is vrij eenvoudig te doen. Het tagging-schema dat ik gebruikte omvat het combineren van een git-hash en een git-tag, als die bestaat. Dit zorgt ervoor dat de tag uniek is en maakt het gemakkelijker om het samenstel waarop deze is gebaseerd te identificeren. DOCKER_USERNAME и DOCKER_PASSWORD zijn gebruikersomgevingsvariabelen die kunnen worden ingesteld met behulp van de Travis CI-interface. Travis CI verwerkt gevoelige gegevens automatisch, zodat deze niet in verkeerde handen vallen.

Hier is het eerste deel van het script deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

Wat het tweede deel van het script zal zijn, hangt volledig af van welke host je gebruikt en hoe de verbinding ermee is georganiseerd. In mijn geval gebruik ik, omdat ik Digital Ocean gebruik, de opdrachten om verbinding te maken met de server doctl. Bij het werken met AWS wordt het hulpprogramma gebruikt aws, enzovoort.

Het opzetten van de server was niet bijzonder moeilijk. Dus heb ik een druppel ingesteld op basis van de basisafbeelding. Opgemerkt moet worden dat het systeem dat ik heb gekozen een eenmalige handmatige installatie van Docker en een eenmalige handmatige lancering van Docker vereist. Ik heb Ubuntu 18.04 gebruikt om Docker te installeren, dus als je ook Ubuntu gebruikt om hetzelfde te doen, kun je gewoon volgen deze eenvoudige gids.

Ik heb het hier niet over specifieke opdrachten voor de service, omdat dit aspect in verschillende gevallen sterk kan variëren. Ik zal alleen een algemeen actieplan geven dat moet worden uitgevoerd nadat ik via SSH verbinding heb gemaakt met de server waarop het project zal worden geïmplementeerd:

• We moeten de container vinden die momenteel actief is en deze stoppen.
• Vervolgens moet u een nieuwe container op de achtergrond starten.
• U moet de lokale poort van de server instellen 80 - hiermee kunt u de site betreden op een adres zoals example.com, zonder de poort op te geven, in plaats van een adres als example.com:5000.
• Ten slotte moet u alle oude containers en afbeeldingen verwijderen.

Hier is het vervolg van het script.

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

Enkele zaken waar u op moet letten

Het is mogelijk dat wanneer u via SSH van Travis CI verbinding maakt met de server, u een waarschuwing ziet die u verhindert door te gaan met de installatie, omdat het systeem wacht op de reactie van de gebruiker.

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

Ik heb geleerd dat een stringsleutel in base64 kan worden gecodeerd om deze op te slaan in een vorm waarin er gemakkelijk en betrouwbaar mee kan worden gewerkt. Tijdens de installatiefase kunt u de openbare sleutel decoderen en naar een bestand schrijven known_hosts om van de bovenstaande fout af te komen.

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

In de praktijk zou dit commando er als volgt uit kunnen zien:

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

En dit is wat het oplevert: een base64-gecodeerde string:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Hier is het hierboven genoemde commando

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

Dezelfde aanpak kan worden gebruikt met een privésleutel bij het tot stand brengen van een verbinding, aangezien u mogelijk een privésleutel nodig heeft om toegang te krijgen tot de server. Wanneer u met de sleutel werkt, hoeft u er alleen maar voor te zorgen dat deze veilig is opgeslagen in een Travis CI-omgevingsvariabele en dat deze nergens wordt weergegeven.

Een ander ding om op te merken is dat u mogelijk het volledige implementatiescript als één regel moet uitvoeren, bijvoorbeeld - with doctl. Dit kan wat extra inspanning vergen.

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL en taakverdeling

Nadat ik alles hierboven had gedaan, was het laatste probleem dat ik tegenkwam dat de server geen SSL had. Omdat ik een Node.js-server gebruik om te forceren om te werken reverse proxy Nginx en Let's Encrypt, je moet veel sleutelen.

Ik wilde echt niet al deze SSL-configuratie handmatig doen, dus heb ik gewoon een load balancer gemaakt en de details ervan in DNS vastgelegd. In het geval van DigitalOcean is het maken van een automatisch vernieuwend, zelfondertekend certificaat op de load balancer bijvoorbeeld een eenvoudige, gratis en snelle procedure. Deze aanpak heeft als bijkomend voordeel dat het heel eenvoudig wordt om SSL in te stellen op meerdere servers die indien nodig achter een load balancer draaien. Hierdoor kunnen de servers zelf helemaal niet aan SSL ‘denken’, maar tegelijkertijd de poort zoals gewoonlijk gebruiken 80. Het instellen van SSL op een load balancer is dus veel eenvoudiger en handiger dan alternatieve methoden voor het instellen van SSL.

Nu kunt u alle poorten op de server sluiten die inkomende verbindingen accepteren, behalve de poort 80, gebruikt om te communiceren met de load balancer en de poort 22 voor SSH. Als gevolg hiervan zal een poging om rechtstreeks toegang te krijgen tot de server op andere poorten dan deze twee mislukken.

Resultaten van

Nadat ik alles had gedaan waar ik het in dit materiaal over had, waren noch het Docker-platform, noch de concepten van geautomatiseerde CI/CD-ketens me meer bang. Ik heb een continue integratieketen kunnen opzetten, waarbij de code wordt getest voordat deze in productie gaat en de code automatisch op de server wordt geïmplementeerd. Dit is allemaal nog relatief nieuw voor mij, en ik weet zeker dat er manieren zijn om mijn geautomatiseerde workflow te verbeteren en efficiënter te maken. Dus als u ideeën heeft over deze kwestie, laat het mij dan weten. me weten. Ik hoop dat dit artikel je heeft geholpen bij je inspanningen. Ik wil geloven dat je na het lezen ervan net zoveel hebt geleerd als ik, terwijl je alles hebt uitgezocht waar ik het over had.

PS In onze marktplaats er is een afbeelding havenarbeider, die met één klik kan worden geïnstalleerd. De werking van containers kunt u controleren op VPS. Alle nieuwe klanten krijgen 3 dagen gratis testen.

Beste lezers! Maakt u gebruik van CI/CD-technologieën in uw projecten?

Bron: www.habr.com