Creació d'una cadena CI/CD i automatització del treball amb Docker

Vaig escriure els meus primers llocs web a finals dels anys 90. Llavors va ser molt fàcil posar-los en condicions de treball. Hi havia un servidor Apache en algun allotjament compartit, es podia accedir a aquest servidor mitjançant FTP escrivint a la línia del navegador alguna cosa com ftp://ftp.example.com. Aleshores calia introduir un nom i una contrasenya i pujar els fitxers al servidor. Hi havia altres temps, llavors tot era més senzill que ara.

Les coses han canviat molt en les últimes dues dècades. Els llocs s'han tornat més complexos, s'han de muntar abans de ser llançats a producció. Un sol servidor s'ha convertit en molts servidors que funcionen darrere dels equilibradors de càrrega, l'ús de sistemes de control de versions s'ha convertit en un lloc habitual.

Per al meu projecte personal, tenia una configuració especial. I sabia que necessitava la capacitat de desplegar un lloc en producció, fent només una acció: escriure codi en una sucursal. master a GitHub. També sabia que no volia gestionar un clúster de Kubernetes enorme, ni utilitzar la tecnologia Docker Swarm, ni mantenir un parc de servidors amb pods, agents i tota mena de complexitats per executar la meva petita aplicació web. Per tal d'aconseguir l'objectiu de fer el treball el més fàcil possible, necessitava familiaritzar-me amb CI/CD.

Si teniu un projecte petit (en el nostre cas, un projecte Node.js) i voleu aprendre a automatitzar el desplegament d'aquest projecte, mentre us assegureu que el que s'emmagatzema al repositori coincideix exactament amb el que funciona en producció, crec que potser us interessa aquest article.

Requisits previs

S'espera que el lector d'aquest article tingui coneixements bàsics de la línia d'ordres i d'escriptura Bash. A més, necessitarà comptes Travis C.I. и docker Hub.

Objectius

No diré que aquest article es pugui anomenar incondicionalment "guia de formació". Aquest és més aviat un document en què parlo del que he après i descric el procés que m'adapta per provar i desplegar codi a producció, realitzat en una passada automatitzada.

Aquí és com va acabar semblant el meu flux de treball.

Per al codi enviat a qualsevol branca del dipòsit que no sigui master, es duen a terme les accions següents:

• Comença la construcció del projecte a Travis CI.
• Es realitzen totes les proves d'unitat, d'integració i d'extrem a extrem.

Només per al codi que acaba en master, es fa el següent:

• Tot l'anterior, a més...
• Creació d'una imatge de Docker basada en el codi, la configuració i l'entorn actuals.
• Allotjament de la imatge a Docker Hub.
• Connexió al servidor de producció.
• Càrrega d'una imatge des de Docker Hub al servidor.
• Atureu el contenidor actual i inicieu-ne un de nou basat en la nova imatge.

Si no sabeu absolutament res sobre Docker, imatges i contenidors, no us preocupeu. T'ho explicaré tot.

Què és CI/CD?

L'abreviatura CI / CD significa "integració contínua / desplegament continu" - "integració contínua / desplegament continu".

▍Integració contínua

La integració contínua és el procés pel qual els desenvolupadors es comprometen amb el dipòsit de codi font principal d'un projecte (normalment una branca master). Al mateix temps, la qualitat del codi es garanteix mitjançant proves automatitzades.

▍Desplegament continu

El desplegament continu és el desplegament automatitzat freqüent de codi a producció. La segona part de l'abreviatura CI / CD de vegades es revela com "entrega continuada" ("entrega continua"). Això és bàsicament el mateix que el "desplegament continu", però el "entrega continu" implica la necessitat de comprometre els canvis manualment abans d'iniciar el procés de desplegament del projecte.

primers passos

L'aplicació on vaig dominar tot això es diu prendre nota. Aquest és un projecte web en el qual estic treballant per prendre notes. Primer vaig intentar fer-ho JAMSstack-projecte, o només una aplicació frontal sense servidor, per tal d'aprofitar les opcions estàndard d'allotjament i desplegament de projectes que ofereix netlify. A mesura que creixia la complexitat de l'aplicació, vaig necessitar crear el seu back-end, la qual cosa significava que hauria de formar la meva pròpia estratègia per a la integració automatitzada i el desplegament automatitzat del projecte.

En el meu cas, l'aplicació és un servidor Express que s'executa en un entorn Node.js, que serveix una aplicació React d'una sola pàgina i admet una API segura del costat del servidor. Aquesta arquitectura segueix una estratègia que es pot trobar a aquest guia d'autenticació de pila completa.

Vaig consultar amb amic, que és un expert en automatització, i li va preguntar què he de fer perquè tot funcioni com vull. Em va donar una idea de com hauria de ser el flux de treball automatitzat descrit a la secció Objectius d'aquest article. Establir objectius com aquest significava que necessitava esbrinar com utilitzar Docker.

estibador

Docker és una eina que, gràcies a la tecnologia de contenidorització, facilita la distribució d'aplicacions, així com el desplegament i l'execució en el mateix entorn, encara que la pròpia plataforma Docker s'executi en entorns diferents. Primer, necessitava posar les meves mans a les eines de línia d'ordres (CLI) de Docker. instrucció La guia d'instal·lació de Docker no és molt clara, però podeu aprendre d'ella que per fer el primer pas de la instal·lació, heu de descarregar Docker Desktop (per a Mac o Windows).

Docker Hub és aproximadament el mateix que GitHub per a repositoris git o registre npm per a paquets JavaScript. Aquest és un dipòsit en línia d'imatges de Docker. Aquí és on es connecta Docker Desktop.

Per tant, per començar amb Docker, heu de fer dues coses:

• Instal·lar escriptori docker.
• Registra't per docker Hub.

Després d'això, podeu comprovar si la CLI de Docker funciona executant l'ordre següent per comprovar la versió de Docker:

docker -v

A continuació, inicieu sessió a Docker Hub introduint el vostre nom d'usuari i contrasenya quan se us demani:

docker login

Per utilitzar Docker, heu d'entendre els conceptes d'imatges i contenidors.

▍Imatges

Una imatge és una mena de plànol que conté instruccions per construir un contenidor. Aquesta és una instantània immutable del sistema de fitxers i la configuració de l'aplicació. Els desenvolupadors poden compartir imatges fàcilment.

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

Aquesta ordre generarà una taula amb el títol següent:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

A continuació, considerarem alguns exemples d'ordres en el mateix format: primer hi ha una ordre amb un comentari i després un exemple del que pot sortir.

▍Contenidors

Un contenidor és un paquet executable que conté tot el necessari per executar una aplicació. Una aplicació amb aquest enfocament sempre funcionarà igual, independentment de la infraestructura: en un entorn aïllat i en el mateix entorn. Estem parlant del fet que les instàncies de la mateixa imatge es llancen en entorns diferents.

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

▍Etiquetes

Una etiqueta és una indicació d'una versió específica d'una imatge.

▍Referència ràpida per a les ordres de Docker

Aquí teniu una visió general d'algunes ordres de Docker d'ús habitual.

Equip

Context

efecte

construcció docker

Imatge

Creació d'una imatge a partir d'un Dockerfile

etiqueta docker

Imatge

Etiquetatge d'imatges

imatges docker

Imatge

Mostra una llista d'imatges

corredera

envàs

Execució d'un contenidor basat en imatges

empenta docker

Imatge

Enviament d'una imatge al Registre

estirada de docker

Imatge

Carregant una imatge des del Registre

portaveus ps

envàs

Llistat de contenidors

poda el sistema docker

Imatge/Contenidor

Eliminació d'envasos i imatges no utilitzats

▍Fitxer Docker

Sé com executar una aplicació de producció localment. Tinc una configuració de paquet web per crear una aplicació React acabada. A continuació, tinc una ordre que inicia un servidor basat en Node.js al port 5000. Es veu així:

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

Cal tenir en compte que no tinc cap exemple d'aplicació per a aquest material. Però aquí, per als experiments, servirà qualsevol aplicació Node senzilla.

Per utilitzar el contenidor, haureu de donar instruccions a Docker. Això es fa mitjançant un fitxer anomenat Dockerfilesituat al directori arrel del projecte. Aquest fitxer, al principi, sembla força incomprensible.

Però el que conté només descriu, en ordres especials, alguna cosa com la configuració d'un entorn de treball. Aquestes són algunes d'aquestes ordres:

• DES DE — Aquesta ordre inicia un fitxer. Especifica la imatge base a partir de la qual es construeix el contenidor.
• COPIA - Copia de fitxers d'una font local a un contenidor.
• DIR. TREBALL - Configuració del directori de treball per a les ordres següents.
• CORRER - Executar ordres.
• EXPOSAR - Configuració del port.
• PUNT D'ENTRADA — Una indicació de l'ordre que s'ha d'executar.

Dockerfile podria semblar una cosa així:

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

Depenent de la imatge base que trieu, és possible que hàgiu d'instal·lar dependències addicionals. El fet és que algunes imatges base (com Node Alpine Linux) estan dissenyades per ser el més compactes possible. Com a resultat, és possible que no incloguin alguns dels programes que espereu.

▍Construir, etiquetar i executar un contenidor

El muntatge local i el llançament del contenidor és, després de tindrem Dockerfileles tasques són força senzilles. Abans d'enviar una imatge a Docker Hub, cal provar-la localment.

▍Assembla

Primer cal recollir imatge, especificant un nom i, opcionalment, una etiqueta (si no s'especifica cap etiqueta, el sistema assignarà automàticament una etiqueta a la imatge latest).

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

Després d'executar aquesta ordre, podeu veure que Docker crea la imatge.

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

La construcció pot trigar un parell de minuts; tot depèn de quantes dependències tinguis. Un cop finalitzada la compilació, podeu executar l'ordre docker images i fes una ullada a la descripció de la teva nova imatge.

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

▍ Llançament

La imatge ha estat creada. I això vol dir que sobre la seva base podeu executar un contenidor. Com que vull poder accedir a l'aplicació que s'executa al contenidor a localhost:5000, i, al costat esquerre de la parella 5000:5000 en el següent conjunt d'ordres 5000. A la part dreta hi ha el port de contenidors.

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

Ara que el contenidor està creat i en funcionament, podeu utilitzar l'ordre docker ps per veure informació sobre aquest contenidor (o podeu utilitzar l'ordre docker ps -a, que mostra informació sobre tots els contenidors, no només els en execució).

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

Si ara aneu a localhost:5000 - podeu veure la pàgina de l'aplicació en execució, que té exactament el mateix aspecte que la pàgina de l'aplicació que s'executa a l'entorn de producció.

▍Assignació i publicació d'etiquetes

Per utilitzar una de les imatges creades al servidor de producció, hem de poder descarregar aquesta imatge des de Docker Hub. Això vol dir que primer heu de crear un dipòsit per al projecte a Docker Hub. Després d'això, tindrem un lloc on podrem enviar la imatge. S'ha de canviar el nom de la imatge perquè el seu nom comenci amb el nostre nom d'usuari de Docker Hub. Això ha d'anar seguit del nom del repositori. Qualsevol etiqueta es pot col·locar al final del nom. A continuació es mostra un exemple de denominació d'imatges segons aquest esquema.

Ara podeu crear la imatge amb un nou nom assignat i executar l'ordre docker push per enviar-lo al dipòsit de Docker Hub.

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

Si tot va bé, la imatge estarà disponible a Docker Hub i es podrà carregar fàcilment al servidor o compartir-la amb altres desenvolupadors.

Següents passos

A hores d'ara, hem verificat que l'aplicació, en forma de contenidor Docker, s'executa localment. Hem penjat el contenidor a Docker Hub. Tot això vol dir que ja hem avançat molt bé cap al nostre objectiu. Ara hem de resoldre dues preguntes més:

• Configuració d'una eina CI per provar i desplegar codi.
• Configurant el servidor de producció perquè pugui descarregar i executar el nostre codi.

En el nostre cas, com a solució CI/CD, utilitzem Travis C.I.. Com a servidor - DigitalOcean.

Cal tenir en compte que aquí podeu utilitzar una altra combinació de serveis. Per exemple, en comptes de Travis CI, podeu utilitzar CircleCI o Github Actions. I en lloc de DigitalOcean - AWS o Linode.

Vam decidir treballar amb Travis CI, i ja tinc alguna cosa configurada en aquest servei. Per tant, ara parlaré breument de com preparar-lo per al treball.

Travis C.I.

Travis CI és una eina per provar i desplegar codi. No vull entrar en els detalls de la creació de Travis CI, ja que cada projecte és únic i no servirà de res. Però parlaré dels conceptes bàsics per començar si decidiu utilitzar Travis CI. Sigui el que trieu: Travis CI, CircleCI, Jenkins o una altra cosa, mètodes de configuració similars s'aplicaran a tot arreu.

Per començar amb Travis CI, aneu a web del projecte i crear un compte. A continuació, integreu Travis CI amb el vostre compte de GitHub. Quan configureu el sistema, haureu d'especificar el repositori que voleu automatitzar i habilitar-hi l'accés. (Jo faig servir GitHub, però estic segur que Travis CI es pot integrar amb BitBucket, GitLab i altres serveis similars).

Cada vegada que s'inicia Travis CI, s'inicia un servidor que executa les ordres especificades al fitxer de configuració, inclosa la implementació de les branques adequades del dipòsit.

▍Cicle de vida laboral

S'ha cridat el fitxer de configuració de Travis CI .travis.yml i emmagatzemat al directori arrel del projecte, admet el concepte d'esdeveniments cicle de vida tasques. Aquests són els esdeveniments, llistats per l'ordre en què es produeixen:

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

▍Proves

Al fitxer de configuració, vaig a configurar un servidor Travis CI local. Vaig triar el node 12 com a idioma i vaig dir al sistema que instal·lés les dependències necessàries per utilitzar Docker.

Tot indicat a .travis.yml, s'executarà en totes les sol·licituds d'extracció a totes les branques del dipòsit, tret que s'especifiqui el contrari. Aquesta és una característica útil, ja que significa que podem provar tot el codi que entra al repositori. Això us permet saber si el codi està llest per ser escrit a la branca. master, i si trencarà el procés de construcció del projecte. En aquesta configuració global, instal·lo tot localment, executo el servidor de desenvolupament Webpack en segon pla (aquesta és una característica del meu flux de treball) i executo les proves.

Si voleu que el vostre dipòsit mostri icones de cobertura de codi, aquí podeu trobar un tutorial ràpid sobre com utilitzar Jest, Travis CI i Overalls per recopilar i mostrar aquesta informació.

Així doncs, aquí teniu el contingut del fitxer .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

Aquí és on acaben les accions que es realitzen per a totes les branques del dipòsit i per a les sol·licituds d'extracció.

▍Desplegament

Partint del supòsit que totes les proves automatitzades s'han completat correctament, opcionalment podem desplegar el codi al servidor de producció. Com que només volem fer això per al codi de branca master, donem al sistema les instruccions adequades a la configuració de desplegament. Abans d'intentar utilitzar el codi que veurem a continuació al vostre projecte, m'agradaria advertir-vos que heu de tenir un script real que es demani per al desplegament.

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

L'script de desplegament fa dues coses:

• Construir, etiquetar i enviar la imatge a Docker Hub mitjançant una eina CI (en el nostre cas és Travis CI).
• Carregant la imatge al servidor, aturant el contenidor antic i iniciant-ne un de nou (en el nostre cas, el servidor funciona a la plataforma DigitalOcean).

Primer, heu de configurar un procés automàtic per crear, etiquetar i enviar la imatge a Docker Hub. Tot això és molt semblant al que ja vam fer manualment, excepte que aquí necessitem una estratègia per assignar etiquetes úniques a les imatges i automatitzar l'inici de sessió. Vaig tenir problemes amb alguns detalls de l'script de desplegament, com ara l'estratègia d'etiquetatge, la sessió, la codificació de claus SSH i l'establiment d'una connexió SSH. Però, per sort, el meu xicot és molt bo amb el bash, així com amb moltes altres coses. Em va ajudar a escriure aquest guió.

Per tant, la primera part de l'script és enviar la imatge a Docker Hub. Fer-ho és bastant senzill. L'esquema d'etiquetatge que he utilitzat implica combinar el hash git i l'etiqueta git si existeix. Això garanteix que l'etiqueta sigui única i fa que sigui més fàcil identificar el conjunt en què es basa. DOCKER_USERNAME и DOCKER_PASSWORD són variables d'entorn definides per l'usuari que es poden configurar mitjançant la interfície Travis CI. Travis CI processarà automàticament les dades sensibles perquè no caiguin en mans equivocades.

Aquí teniu la primera part del guió 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}

Quina serà la segona part de l'script depèn completament de l'amfitrió que utilitzeu i de com s'organitzi la connexió amb ell. En el meu cas, com que faig servir Digital Ocean, les ordres s'utilitzen per connectar-me al servidor doctl. Quan es treballa amb Aws, s'utilitzarà la utilitat aws, etcètera.

Configurar el servidor no va ser especialment difícil. Per tant, vaig configurar una gota basada en la imatge base. Cal tenir en compte que el sistema que he escollit requereix una instal·lació manual única de Docker i un inici manual de Docker. Vaig utilitzar Ubuntu 18.04 per instal·lar Docker, així que si també feu servir Ubuntu, només podeu seguir aquesta orientació senzilla.

No parlo d'ordres concretes per al servei aquí, ja que aquest aspecte pot variar molt en diferents casos. Només donaré un pla general d'acció que es realitzarà després de connectar-me mitjançant SSH al servidor on es desplegarà el projecte:

• Heu de trobar el contenidor que s'està executant actualment i aturar-lo.
• Aleshores, heu d'iniciar un contenidor nou en segon pla.
• Haureu de configurar el port local del servidor a 80 - això us permetrà entrar al lloc a l'adreça del formulari example.com, sense especificar un port, en lloc d'utilitzar una adreça com example.com:5000.
• I, finalment, cal eliminar tots els contenidors i imatges antics.

Aquí teniu la continuació del guió.

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

Algunes coses a tenir en compte

És possible que quan us connecteu al servidor mitjançant SSH des de Travis CI, vegeu un avís que no us permetrà continuar amb la instal·lació, ja que el sistema esperarà la resposta de l'usuari.

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

Vaig aprendre que una clau de cadena es pot codificar a base64 per tal d'emmagatzemar-la en una forma en què es pugui treballar de manera còmoda i fiable. En l'etapa d'instal·lació, podeu descodificar la clau pública i escriure-la en un fitxer known_hosts per tal d'eliminar l'error anterior.

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

A la pràctica, aquesta ordre podria semblar així:

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

I això és el que ofereix: una cadena codificada en base64:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

Aquí teniu la comanda esmentada anteriorment

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

El mateix enfocament es pot utilitzar amb una clau privada quan s'estableix una connexió, ja que és possible que necessiteu una clau privada per accedir al servidor. Quan treballeu amb una clau, només heu d'assegurar-vos que s'emmagatzema de manera segura en una variable d'entorn de Travis CI i que no es mostra enlloc.

Una altra cosa a tenir en compte és que és possible que hàgiu d'executar tot l'script de desplegament com una línia única, per exemple amb doctl. Això pot requerir un esforç addicional.

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

TLS/SSL i equilibri de càrrega

Després de fer tot l'anterior, l'últim problema que vaig tenir va ser que el servidor no tenia SSL. Com que estic fent servir un servidor Node.js, per forçar treballar proxy invers Nginx i Let's Encrypt, heu de fer moltes coses.

Realment no volia fer tots aquests paràmetres SSL manualment, així que només vaig crear un equilibrador de càrrega i vaig registrar informació al respecte al DNS. En el cas de DigitalOcean, per exemple, crear un certificat autofirmat de renovació automàtica a l'equilibrador de càrrega és un procediment senzill, gratuït i ràpid. Aquest enfocament té l'avantatge afegit de fer que sigui molt fàcil configurar SSL en diversos servidors que s'executen darrere d'un equilibrador de càrrega si cal. Això permet que els propis servidors no "pensin" gens en SSL, però al mateix temps utilitzen, com és habitual, el port 80. Per tant, configurar SSL en un equilibrador de càrrega és molt més fàcil i convenient que els mètodes alternatius de configuració de SSL.

Ara podeu tancar tots els ports del servidor que acceptin connexions entrants, excepte el port 80, que s'utilitza per comunicar-se amb l'equilibrador de càrrega i el port 22 per a SSH. Com a resultat, un intent de contactar amb el servidor directament en qualsevol port diferent d'aquests dos fallarà.

Resultats de

Després de fer tot el que he parlat en aquest article, ni la plataforma Docker ni el concepte de cadenes automatitzades de CI/CD ja no em van fer por. Vaig poder configurar una cadena d'integració contínua, durant la qual el codi es prova abans d'entrar en producció i el codi es desplega automàticament al servidor. Tot això encara és relativament nou per a mi, i estic segur que hi ha maneres de millorar el meu flux de treball automatitzat i fer-lo més eficient. Així que si teniu alguna idea sobre això, doneu-ho em saber. Espero que aquest article us hagi ajudat en els vostres esforços. Vull creure que llegint-lo, vas aprendre tant com jo vaig aprendre mentre m'ocupava de tot el que hi vaig explicar.

PS En la nostra mercat hi ha una imatge estibador, que s'instal·la amb un sol clic. Podeu comprovar el funcionament dels contenidors VPS. Tots els clients nous reben 3 dies de proves de manera gratuïta.

Benvolguts lectors! Utilitzeu tecnologies CI/CD en els vostres projectes?

Font: www.habr.com