В какой то момент разработки мы приходим к том, что нам нужно развернуть наше приложение на реальном сервере. Самый простой и долгий способ: собирать приложение локально, передавать на сервер по SFTP, затем по SSH рестартовать службу приложения (предварительно написанную для systemd). Хотелось бы меньше действий, щелкнул по кнопке и все само развернулось (CI/DI). Для этого можно написать свой сервис, найти готовое ПО типа Jenkins  или использовать CI/DI от Github, который называется GitHub Actions. Рассмотрим вариант с GitHub Actions как самый быстрый в реализации.

Разворачивать будем приложение написанное на Go. Считаем, что арендованный VPS у нас уже есть. Я выбрал VPS на reg.ru с установленным образом Docker.

На наш сервер установим runner для GitHub Actions

Сперва создаем пользователя, т.к. под рутом нельзя запускать runner и включаем его в группу sudo

sudo useradd app -p mypassword
sudo usermod -a -G sudo app
sudo usermod -a -G docker app

Так же убедитесь, что у исполняемого файла /usr/bin/docker-compose стоят права 711 или 755 (разрешен запуск всем пользователям, а не только владельцу и его группе)

Логинимся под нашим новым пользователем. Далее следуем инструкции по добавлению своего runner, которая находится в настройках проекта github:

Из инструкции (копируйте команды из инструкции, там версия новее и url/token указан):

# Create a folder
$ mkdir actions-runner && cd actions-runner
# Download the latest runner package
$ curl -o actions-runner-linux-x64-2.304.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.304.0/actions-runner-linux-x64-2.304.0.tar.gz
# Extract the installer
$ tar xzf ./actions-runner-linux-x64-2.304.0.tar.gz

# Create the runner and start the configuration experience
$ ./config.sh --url <ваш url github> --token <здесь ваш токен>
# Last step, run it!
$ ./run.sh

После запуска отвечаем на несколько вопросов установщика и runner готов.

Далее запускаем его как сервис systemd

sudo ./svc.sh install
sudo ./svc.sh start

На этом настройка runner закончена.

Подготовим данные для нашего приложения и разместим docker-compose файл

Отдельную папку создавать не будем, приложение будет запускаться из домашней папке пользователя (/home/app). Размещаем в папке файлы нужные для работы приложения. У меня это файл .env с переменными среды и папка data в которой хранится БД.

Создаем файл docker-compose.yml в домашней папке:

  app:
    image: ghcr.io/<имя репо>:<имя ветки>
    env_file:
      - .env
    ports:
      - "80:1323"
    volumes:
      - ./data:/data

Где <имя репо>:<имя ветки> это данные вашего репозитория, например itmind/testdeploy:main

Образ будет скачан с нашего приватного контейнера GitHub Packages, в который запишется в процессе CI/DI. У GitHub в базовую бесплатную подписку входит определенное количество минут и объема пространства которого достаточно, что бы каждый месяц не платить.

Создаем GitHub Actions workflow

Создать можно как интерактивно, через web-интерфейс, так и просто создав файл локально в папке проекта по пути .github/workflows. Сделаем там файл go.yml следующего содержания:

name: Go

on:
  push:
    branches: [ "main" ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:

  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Set up Go
      uses: actions/setup-go@v4
      with:
        go-version: 'stable'

    - name: Build
      run: go build -v ./...

    - name: Test
      run: go test -v ./...

  build-and-push-image:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Log in to the Container registry
        uses: docker/login-action@v2
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v4
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    runs-on: self-hosted
    needs: build-and-push-image

    steps:
      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Run container
        run: |
          cd ~
          docker-compose up --build --pull=always &

Наш workflow состоит за 3 задач и запускается при пуше в ветку main.

  1. Собираем приложение go и запускаем тесты в образе ubuntu
  2. Если сборка и тесты прошли, то собираем образ по Dockerfile (ниже опишу) и отправляем его в репозиторий GitHub Packages
  3. На нашем сервера, через наш runner, выполняем команду в домашней папке. Ключ –build нужен, что бы образ всегда скачивался заново.

Теперь при пуше в ветку main на GitHub через несколько минут обновится приложение на сервере. В версии actions/setup-go@v4 кэш включен, поэтому при повторной сборке зависимости заново скачиваться не будут. Так же включен кэш для слоев образа докера.

Файл Dockerfile в корне проекта

FROM golang:alpine AS builder
ENV CGO_ENABLED 1
RUN apk update && apk add --no-cache git ca-certificates tzdata upx && update-ca-certificates
#Установка gcc и библиотек для разработки
RUN apk add --update alpine-sdk
WORKDIR /build
ADD go.mod .
ADD go.sum .
RUN go mod download
COPY . .
RUN CGO_ENABLED=1 GOARCH=amd64 GOOS=linux go build -ldflags "-s -w -extldflags '-static'" -o app
# Сжатие исполняемого файла
RUN upx ./hds

FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo/
COPY --from=builder /build/app /app
CMD ["/app"]

Multistage сборка. Сначала компилируем приложение в одном образе, затем передаем его в другой образ.

Параметры -ldflags “-s -w -extldflags ‘-static'” нуны что бы исключить всю отладочную информацию и включить в исполняемый файл зависимые библиотеки. К сожалению libc6 не линкуется статически Если не включить зависимые библиотеки (libc6), то например собрав приложение в Ubuntu 22.04 оно не запустится на Ubuntu 20.04, т.к. там другая версия libc6.

Так же в итоговый образ включены корневые сертификаты для использования SSL (HTTPS)

Продолжение смотрите здесь

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *