Skep 'n CI / CD-ketting en outomatisering van werk met Docker

Ek het my eerste webwerwe in die laat 90's geskryf. Toe was dit baie maklik om hulle in werkende toestand te bring. Daar was 'n Apache-bediener op een of ander gedeelde hosting, hierdie bediener kon verkry word via FTP deur iets soos in die blaaierreël te skryf ftp://ftp.example.com. Dan was dit nodig om 'n naam en wagwoord in te voer en die lêers op die bediener op te laai. Daar was ander tye, alles was toe eenvoudiger as nou.

Dinge het baie verander in die afgelope twee dekades. Terreine het meer kompleks geword, dit moet saamgestel word voordat dit in produksie vrygestel word. Een enkele bediener het baie bedieners geword wat agter lasbalanseerders loop, die gebruik van weergawebeheerstelsels het alledaags geword.

Vir my persoonlike projek het ek 'n spesiale konfigurasie gehad. En ek het geweet dat ek die vermoë nodig het om 'n webwerf in produksie te ontplooi, deur net een aksie uit te voer: die skryf van kode na 'n tak master op GitHub. Ek het ook geweet dat ek nie 'n groot Kubernetes-kluster wil bestuur, of Docker Swarm-tegnologie wil gebruik, of 'n bedienerpark met peule, agente en allerhande ander kompleksiteite wil onderhou om my klein webtoepassing te laat loop nie. Om die doelwit te bereik om werk so maklik moontlik te maak, moes ek met CI/CD kennis maak.

As jy 'n klein projek het (in ons geval, 'n Node.js-projek) en graag wil leer hoe om die ontplooiing van hierdie projek te outomatiseer, terwyl jy seker maak dat wat in die bewaarplek gestoor word presies ooreenstem met wat in produksie werk, dink ek jy sal dalk in hierdie artikel belangstel.

Voorvereistes

Daar word van die leser van hierdie artikel verwag om basiese opdragreël en Bash-skrifkennis te hê. Daarbenewens sal hy rekeninge nodig hê Travis C.I. и Docker-spilpunt.

Doelwitte

Ek sal nie sê dat hierdie artikel onvoorwaardelik 'n "opleidingsgids" genoem kan word nie. Dit is meer 'n dokument waarin ek praat oor wat ek geleer het en die proses beskryf wat my pas vir die toets en ontplooiing van kode na produksie, uitgevoer in een outomatiese pas.

Hier is hoe my werkvloei uiteindelik gelyk het.

Vir kode gedruk na enige tak van die bewaarplek anders as master, word die volgende aksies uitgevoer:

• Projekbou op Travis CI begin.
• Alle eenheid-, integrasie- en end-tot-end-toetse word uitgevoer.

Slegs vir kode wat in beland master, word die volgende gedoen:

• Al die bogenoemde, plus ...
• Bou 'n Docker-beeld gebaseer op die huidige kode, instellings en omgewing.
• Hosting van die prent op Docker Hub.
• Verbinding met die produksiebediener.
• Laai 'n prent van Docker Hub na die bediener op.
• Stop die huidige houer en begin 'n nuwe een gebaseer op die nuwe prent.

As jy absoluut niks van Docker, beelde en houers weet nie, moenie bekommerd wees nie. Ek sal jou alles daarvan vertel.

Wat is CI/CD?

Die afkorting CI / CD staan ​​vir "continuous integration / continuous deployment" - "continuous integration / continuous deployment".

▍ Deurlopende integrasie

Deurlopende integrasie is die proses waardeur ontwikkelaars hulle verbind tot 'n projek se hoofbronkodebewaarplek (gewoonlik 'n tak) master). Terselfdertyd word die kwaliteit van die kode verseker deur outomatiese toetsing.

▍ Deurlopende ontplooiing

Deurlopende ontplooiing is die gereelde outomatiese ontplooiing van kode na produksie. Die tweede deel van die afkorting CI / CD word soms geopenbaar as "voortdurende aflewering" ("voortdurende aflewering"). Dit is basies dieselfde as "voortdurende ontplooiing", maar "voortdurende aflewering" impliseer die behoefte om veranderinge handmatig toe te pas voordat die projekontplooiingsproses begin word.

Aan die slag

Die toepassing waarop ek dit alles bemeester het, word genoem Kennis neem. Dit is 'n webprojek waaraan ek werk om aantekeninge te maak. Eers het ek probeer doen JAMStack-projek, of net 'n front-end toepassing sonder 'n bediener, om voordeel te trek uit die standaard hosting en projek ontplooiing opsies wat dit bied netifiseer. Namate die kompleksiteit van die toepassing gegroei het, moes ek die agterkant daarvan skep, wat beteken het dat ek my eie strategie vir outomatiese integrasie en outomatiese ontplooiing van die projek sou moes vorm.

In my geval is die toepassing 'n Express-bediener wat in 'n Node.js-omgewing loop, wat 'n React-toepassing van een bladsy bedien en 'n veilige bedienerkant API ondersteun. Hierdie argitektuur volg 'n strategie wat gevind kan word in hierdie volledige stapel verifikasie gids.

Ek het gekonsulteer met vriend, wat 'n outomatiseringskenner is, en hom gevra wat ek moet doen om dit alles te laat werk soos ek wil. Hy het my 'n idee gegee van hoe die outomatiese werkvloei wat in die Doelwitte-afdeling van hierdie artikel uiteengesit word, moet lyk. Om doelwitte soos hierdie te stel, het beteken dat ek moes uitvind hoe om Docker te gebruik.

Docker

Docker is 'n instrument wat, danksy houer-tegnologie, dit maklik maak om toepassings te versprei, sowel as om dit in dieselfde omgewing te ontplooi en te laat loop, selfs al loop die Docker-platform self in verskillende omgewings. Eerstens moes ek die Docker command line tools (CLI) in die hande kry. instruksie Die installasiegids vir Docker is nie baie duidelik nie, maar u kan daaruit leer dat u Docker Desktop (vir Mac of Windows) moet aflaai om die eerste stap van die installasie te neem.

Docker Hub is omtrent dieselfde as GitHub vir git-bewaarplekke, of register NPM vir JavaScript-pakkette. Dit is 'n aanlyn bewaarplek vir Docker-beelde. Dit is waar Docker Desktop aan koppel.

Dus, om met Docker te begin, moet u twee dinge doen:

• Installeer DockerDesktop.
• Registreer vir Docker-spilpunt.

Daarna kan u kyk of die Docker CLI werk deur die volgende opdrag uit te voer om die Docker-weergawe na te gaan:

docker -v

Meld dan aan by Docker Hub deur u gebruikersnaam en wagwoord in te voer wanneer gevra word:

docker login

Om Docker te gebruik, moet u die konsepte van beelde en houers verstaan.

▍ Beelde

'n Beeld is 'n soort bloudruk wat instruksies bevat vir die bou van 'n houer. Dit is 'n onveranderlike momentopname van die lêerstelsel en toepassinginstellings. Ontwikkelaars kan maklik beelde deel.

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

Hierdie opdrag sal 'n tabel met die volgende titel uitvoer:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

Vervolgens sal ons 'n paar voorbeelde van opdragte in dieselfde formaat oorweeg - eers is daar 'n opdrag met 'n opmerking, en dan 'n voorbeeld van wat dit kan uitvoer.

▍ Houers

'n Houer is 'n uitvoerbare pakket wat alles bevat wat nodig is om 'n toepassing te laat loop. 'n Toepassing met hierdie benadering sal altyd dieselfde werk, ongeag die infrastruktuur: in 'n geïsoleerde omgewing en in dieselfde omgewing. Ons praat oor die feit dat gevalle van dieselfde beeld in verskillende omgewings bekendgestel word.

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

▍Tags

'n Merker is 'n aanduiding van 'n spesifieke weergawe van 'n prent.

▍ Vinnige verwysing vir Docker-opdragte

Hier is 'n oorsig van 'n paar algemeen gebruikte Docker-opdragte.

Span

konteks

effek

docker bou

beeld

Bou 'n prent vanaf 'n Dockerfile

docker tag

beeld

Beeldmerking

docker beelde

beeld

Lys beelde

docker run

Houer

Begin 'n beeld-gebaseerde houer

docker druk

beeld

Stuur 'n prent na die register

docker-trek

beeld

Laai 'n prent uit die register

docker ps

Houer

Lys houers

docker stelsel snoei

Beeld/houer

Verwyder ongebruikte houers en beelde

▍Dockerfile

Ek weet hoe om 'n produksietoepassing plaaslik te laat loop. Ek het 'n webpack-konfigurasie om 'n voltooide React-toepassing te bou. Vervolgens het ek 'n opdrag wat 'n Node.js-gebaseerde bediener op die poort begin 5000. Dit lyk so:

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

Daar moet kennis geneem word dat ek nie 'n voorbeeldtoepassing vir hierdie materiaal het nie. Maar hier, vir eksperimente, sal enige eenvoudige Node-toepassing deug.

Om die houer te gebruik, sal jy instruksies aan Docker moet gee. Dit word gedoen deur 'n lêer genaamd Dockerfilegeleë in die wortelgids van die projek. Hierdie lêer lyk aanvanklik nogal onverstaanbaar.

Maar wat dit bevat, beskryf slegs, in spesiale opdragte, iets soos die opstel van 'n werksomgewing. Hier is 'n paar van daardie opdragte:

• UIT — Hierdie opdrag begin 'n lêer. Dit spesifiseer die basisbeeld waaruit die houer gebou is.
• AFSKRIF - Kopieer lêers van 'n plaaslike bron na 'n houer.
• WERKDIR - Stel die werkgids vir die volgende opdragte op.
• RUN - Voer opdragte uit.
• BLOOT TE STEL - Poortinstelling.
• INGANGSPUNT — 'n Aanduiding van die opdrag wat uitgevoer moet word.

Dockerfile kan so iets lyk:

# Загрузить базовый образ
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

Afhangende van die basisbeeld wat jy kies, sal jy dalk bykomende afhanklikhede moet installeer. Die feit is dat sommige basisbeelde (soos Node Alpine Linux) ontwerp is om so kompak as moontlik te wees. Gevolglik sluit hulle dalk nie sommige van die programme in wat jy verwag nie.

▍ Bou, merk en bestuur 'n houer

Plaaslike samestelling en bekendstelling van die houer is, nadat ons het Dockerfiledie take is redelik eenvoudig. Voordat 'n prent na Docker Hub gestoot word, moet dit plaaslik getoets word.

▍Vergadering

Eerstens moet jy versamel beeld, spesifiseer 'n naam, en, opsioneel, 'n merker (indien geen merker gespesifiseer is nie, sal die stelsel outomaties 'n merker aan die prent toewys latest).

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

Nadat u hierdie opdrag uitgevoer het, kan u kyk hoe Docker die prent bou.

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

Bou kan 'n paar minute neem - dit hang alles af van hoeveel afhanklikhede jy het. Nadat die bou voltooi is, kan jy die opdrag uitvoer docker images en kyk na die beskrywing van jou nuwe prent.

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

▍Begin

Die beeld is geskep. En dit beteken dat jy op grond daarvan 'n houer kan bestuur. Aangesien ek in staat wil wees om toegang te verkry tot die toepassing wat in die houer loop by localhost:5000, i, aan die linkerkant van die paar 5000:5000 in die volgende opdragstel 5000. Aan die regterkant is die houerpoort.

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

Noudat die houer geskep en aan die gang is, kan jy die opdrag gebruik docker ps om na inligting oor hierdie houer te kyk (of jy kan die opdrag gebruik docker ps -a, wat inligting oor alle houers vertoon, nie net lopende houers nie).

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

As jy nou gaan na localhost:5000 - jy kan die bladsy van die lopende toepassing sien, wat presies dieselfde lyk as die bladsy van die toepassing wat in die produksie-omgewing loop.

▍Tagtoewysing en publikasie

Om een ​​van die geskepte beelde op die produksiebediener te gebruik, moet ons hierdie beeld vanaf Docker Hub kan aflaai. Dit beteken dat u eers 'n bewaarplek vir die projek op Docker Hub moet skep. Daarna sal ons 'n plek hê waarheen ons die beeld kan stuur. Die prent moet hernoem word sodat sy naam met ons Docker Hub-gebruikersnaam begin. Dit moet gevolg word deur die naam van die bewaarplek. Enige merker kan aan die einde van die naam geplaas word. Hieronder is 'n voorbeeld van die naam van beelde volgens hierdie skema.

Nou kan jy die prent bou met 'n nuwe naam wat daaraan toegeken is en die opdrag uitvoer docker push om dit na die Docker Hub-bewaarplek te stoot.

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

As alles goed gaan, sal die prent op Docker Hub beskikbaar wees en kan dit maklik na die bediener opgelaai of met ander ontwikkelaars gedeel word.

Volgende stappe

Teen hierdie tyd het ons geverifieer dat die toepassing, in die vorm van 'n Docker-houer, plaaslik loop. Ons het die houer na Docker Hub opgelaai. Dit alles beteken dat ons reeds baie goeie vordering gemaak het na ons doelwit. Nou moet ons nog twee vrae oplos:

• Die opstel van 'n CI-instrument vir die toets en ontplooiing van kode.
• Stel die produksiebediener op sodat dit ons kode kan aflaai en laat loop.

In ons geval, as 'n CI / CD-oplossing, gebruik ons Travis C.I.. As 'n bediener - DigitalOseaan.

Daar moet kennis geneem word dat u hier 'n ander kombinasie van dienste kan gebruik. Byvoorbeeld, in plaas van Travis CI, kan jy CircleCI of Github Actions gebruik. En in plaas van DigitalOcean - AWS of Linode.

Ons het besluit om saam met Travis CI te werk, en ek het reeds iets in hierdie diens opgestel. Daarom sal ek nou kortliks praat oor hoe om dit vir werk voor te berei.

Travis C.I.

Travis CI is 'n instrument om kode te toets en te ontplooi. Ek wil nie ingaan op die besonderhede van die opstel van Travis CI nie, aangesien elke projek uniek is en dit nie veel goed sal doen nie. Maar ek sal die basiese beginsels dek om jou aan die gang te kry as jy besluit om Travis CI te gebruik. Wat jy ook al kies - Travis CI, CircleCI, Jenkins, of iets anders, soortgelyke konfigurasiemetodes sal oral van toepassing wees.

Om met Travis CI te begin, gaan na projek webwerf en skep 'n rekening. Integreer dan Travis CI met jou GitHub-rekening. Wanneer u die stelsel opstel, moet u die bewaarplek spesifiseer wat u wil outomatiseer en toegang daartoe moontlik maak. (Ek gebruik GitHub, maar ek is seker Travis CI kan met BitBucket, GitLab en ander soortgelyke dienste integreer).

Elke keer as Travis CI begin word, word 'n bediener begin wat die opdragte uitvoer wat in die konfigurasielêer gespesifiseer word, insluitend die implementering van die toepaslike takke van die bewaarplek.

▍ Werk lewensiklus

Travis CI-konfigurasielêer genoem .travis.yml en gestoor in die projek se wortelgids, ondersteun die konsep van gebeure lewens siklus take. Hier is die gebeure, gelys in die volgorde waarin hulle plaasvind:

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

▍ Toets

In die konfigurasielêer gaan ek 'n plaaslike Travis CI-bediener opstel. Ek het Node 12 as die taal gekies en die stelsel gesê om die afhanklikhede te installeer wat nodig is om Docker te gebruik.

Alles gelys in .travis.yml, sal uitgevoer word op alle trekversoeke na alle takke van die bewaarplek, tensy anders gespesifiseer. Dit is 'n nuttige kenmerk, aangesien dit beteken dat ons al die kode wat in die bewaarplek gaan, kan toets. Dit laat jou toe om te weet of die kode gereed is om na die tak geskryf te word. master, en of dit die bouproses van die projek sal breek. In hierdie globale konfigurasie installeer ek alles plaaslik, hardloop die Webpack-ontwikkelaarbediener op die agtergrond (dit is 'n kenmerk van my werkvloei) en voer die toetse uit.

As jy wil hê dat jou bewaarplek kodedekking-ikone moet vertoon, hier jy kan 'n vinnige handleiding vind oor hoe om Jest, Travis CI en oorpakke te gebruik om hierdie inligting te versamel en te vertoon.

So hier is die inhoud van die lêer .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 die aksies wat uitgevoer word vir alle vertakkings van die bewaarplek en vir trekversoeke eindig.

▍ Ontplooiing

Gebaseer op die aanname dat alle outomatiese toetse suksesvol voltooi is, kan ons die kode opsioneel na die produksiebediener ontplooi. Aangesien ons dit net vir takkode wil doen master, gee ons die stelsel die toepaslike instruksies in die ontplooiing-instellings. Voordat jy probeer om die kode te gebruik waarna ons volgende in jou projek sal kyk, wil ek jou graag waarsku dat jy 'n werklike skrif moet hê wat vir ontplooiing geroep word.

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

Die ontplooiingskrip doen twee dinge:

• Bou, merk en stuur die prent na Docker Hub met behulp van 'n CI-instrument (in ons geval is dit Travis CI).
• Laai die prent op die bediener, stop die ou houer en begin 'n nuwe een (in ons geval loop die bediener op die DigitalOcean-platform).

Eerstens moet u 'n outomatiese proses opstel om die beeld te bou, te merk en na Docker Hub te stoot. Dit alles is baie soortgelyk aan wat ons reeds met die hand gedoen het, behalwe dat ons hier 'n strategie nodig het om unieke etikette aan beelde toe te ken en aanmelding te outomatiseer. Ek het gesukkel met sommige besonderhede van die ontplooiingskrip, soos merkstrategie, aanmeld, kodering van SSH-sleutels, die vestiging van 'n SSH-verbinding. Maar gelukkig is my kêrel baie goed met bash, sowel as met baie ander dinge. Hy het my gehelp om hierdie draaiboek te skryf.

Dus, die eerste deel van die skrif stuur die prent na Docker Hub. Om dit te doen is redelik eenvoudig. Die etiketteringskema wat ek gebruik het, behels die kombinasie van die git-hash en die git-tag indien dit bestaan. Dit verseker dat die merker uniek is en maak dit makliker om die samestelling waarop dit gebaseer is te identifiseer. DOCKER_USERNAME и DOCKER_PASSWORD is gebruikergedefinieerde omgewingsveranderlikes wat met die Travis CI-koppelvlak ingestel kan word. Travis CI sal outomaties sensitiewe data verwerk sodat dit nie in die verkeerde hande val nie.

Hier is die eerste deel van die draaiboek 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 die tweede deel van die skrif sal wees, hang geheel en al af van watter gasheer jy gebruik en hoe die verbinding daarmee georganiseer is. In my geval, aangesien ek Digital Ocean gebruik, word die opdragte gebruik om aan die bediener te koppel doctl. Wanneer jy met Aws werk, sal die hulpprogram gebruik word aws, en so aan.

Die opstel van die bediener was nie besonder moeilik nie. So, ek stel 'n druppel op gebaseer op die basisbeeld. Daar moet kennis geneem word dat die stelsel wat ek gekies het 'n eenmalige handinstallasie van Docker en 'n eenmalige handbegin van Docker vereis. Ek het Ubuntu 18.04 gebruik om Docker te installeer, so as jy ook Ubuntu gebruik, kan jy net volg hierdie eenvoudige leiding.

Ek praat nie hier van spesifieke opdragte vir die diens nie, aangesien hierdie aspek in verskillende gevalle baie kan verskil. Ek sal net 'n algemene plan van aksie gee wat uitgevoer moet word nadat ek via SSH gekoppel is aan die bediener waar die projek ontplooi sal word:

• Jy moet die houer vind wat tans loop en dit stop.
• Dan moet jy 'n nuwe houer in die agtergrond begin.
• Jy sal die bediener se plaaslike poort op moet stel 80 - dit sal jou toelaat om die webwerf by die adres van die vorm in te voer example.com, sonder om 'n poort te spesifiseer, eerder as om 'n adres soos example.com:5000.
• En uiteindelik moet jy alle ou houers en beelde verwyder.

Hier is die voortsetting van die draaiboek.

# Найти 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

Sommige dinge om voor op te let

Dit is moontlik dat wanneer jy via SSH vanaf Travis CI aan die bediener koppel, jy 'n waarskuwing sal sien wat jou nie sal toelaat om voort te gaan met die installasie nie, aangesien die stelsel sal wag vir die gebruiker se reaksie.

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)?

Ek het geleer dat 'n stringsleutel in base64 geënkodeer kan word om dit te stoor in 'n vorm waarin dit gerieflik en betroubaar mee gewerk kan word. Op die installasie stadium kan jy die publieke sleutel dekodeer en dit na 'n lêer skryf known_hosts om van bogenoemde fout ontslae te raak.

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

In die praktyk kan hierdie opdrag soos volg lyk:

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 hier is wat dit gee - 'n base64-gekodeerde string:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Hier is die opdrag hierbo genoem

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

Dieselfde benadering kan met 'n private sleutel gebruik word wanneer 'n verbinding tot stand gebring word, aangesien jy moontlik 'n private sleutel nodig het om toegang tot die bediener te kry. Wanneer jy met 'n sleutel werk, hoef jy net te verseker dat dit veilig in 'n Travis CI-omgewingsveranderlike gestoor word, en dat dit nêrens vertoon word nie.

Nog 'n ding om op te let is dat jy dalk die hele implementeringskrip as 'n enkele reël moet laat loop, byvoorbeeld met doctl. Dit kan 'n bietjie ekstra moeite verg.

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

TLS/SSL en lasbalansering

Nadat ek al die bogenoemde gedoen het, was die laaste probleem wat ek gehad het dat die bediener nie SSL gehad het nie. Aangesien ek 'n Node.js-bediener gebruik, om te dwing om te werk omgekeerde proxy Nginx en Let's Encrypt, jy moet baie peuter.

Ek wou regtig nie al hierdie SSL-instellings met die hand doen nie, so ek het net 'n lasbalanseerder geskep en inligting daaroor in DNS aangeteken. In die geval van DigitalOcean, byvoorbeeld, is die skep van 'n outomatiese hernuwing self-ondertekende sertifikaat op die load balancer 'n eenvoudige, gratis en vinnige prosedure. Hierdie benadering het die bykomende voordeel dat dit baie maklik is om SSL op te stel op verskeie bedieners wat agter 'n lasbalanseerder loop indien nodig. Dit laat die bedieners self toe om glad nie aan SSL te "dink" nie, maar terselfdertyd, soos gewoonlik, die poort te gebruik 80. Die konfigurasie van SSL op 'n lasbalanseerder is dus baie makliker en geriefliker as alternatiewe SSL-konfigurasiemetodes.

Nou kan jy alle poorte op die bediener sluit wat inkomende verbindings aanvaar - behalwe die poort 80, wat gebruik word om met die lasbalanseerder en die poort te kommunikeer 22 vir SSH. As gevolg hiervan sal 'n poging om die bediener op enige ander poorte as hierdie twee direk te kontak, misluk.

Resultate van

Nadat ek alles gedoen het waaroor ek in hierdie artikel gepraat het, het nie die Docker-platform of die konsep van outomatiese CI / CD-kettings my meer bang gemaak nie. Ek kon 'n deurlopende integrasieketting opstel, waartydens die kode getoets word voordat dit in produksie gaan en die kode outomaties na die bediener ontplooi word. Dit alles is nog relatief nuut vir my, en ek is seker daar is maniere om my outomatiese werkvloei te verbeter en dit meer doeltreffend te maak. So as jy enige idees hieroor het - gee vir my weet. Ek hoop dat hierdie artikel jou gehelp het in jou pogings. Ek wil glo dat deur dit te lees, jy soveel geleer het as wat ek geleer het terwyl ek met alles behandel het waarvan ek daarin vertel het.

PS In ons markplek daar is 'n beeld Docker, wat met een klik geïnstalleer word. Jy kan kyk of die houers werk VPS. Alle nuwe kliënte kry 3 dae se toetsing gratis.

Beste lesers! Gebruik jy CI/CD-tegnologieë in jou projekte?

Bron: will.com