Денис Матаков

Блог технического руководителя

Присоединяйтесь к моему телеграм-каналу CTO Лайфхаки

Подробнее о моих услугах для бизнеса

  • Bulma для всех, кто боится Bootstrap

    Bulma для всех, кто боится Bootstrap

    Как начинающий разработчик, я, безусловно, пользовался бутстрапом. Это такой красивый CSS-фреймворк, который помогает сайтам от разработчиков выглядеть симпатично даже без фронтендера в команде. Но любая попытка сделать красивую кнопку заводила меня в документацию, так как набор переменных в стилях там запомнить совершенно невозможно.

    И вот тут на помощь пришла Bulma. Это по сути своей тот же Bootstrap, только с человеческими названиями классов. Хотите кнопку? Класс называется button. Хотите колонки? Пишите columns, а внутри для каждой колонки column. Считаю, что Бульму надо включить обязательное изучение во всех курсах бэкендеров.

    Обязательно посмотрите их вводное видео:

  • Закончил курс Яндекс.Практикума Python-разработчик

    Закончил курс Яндекс.Практикума Python-разработчик

    Завершилась большая и интересная глава в моей жизни. В начале прошлого лета в разгар эпидемии и в расцвет онлайн-обучения я решил, что стоит воспользоваться возможностью и получить, наконец, образование в области программирования и разработки. Все это время я оставался самоучкой, знал много разных языков и синтаксисов, но из-за отсутствия базового понимания взаимодействия элементов инфраструктуры разработки я не мог сдвинуться с мертвой точки. Мне все легко давалось до определенного предела, а дальше — сразу лес густой, иначе не скажешь. Но эти 9 месяцев все изменили.

    Базовый синтаксис Питона я знал еще до Яндекс.Практикума, заканчивал курсы от Гугла. Поэтому первая часть далась мне относительно легко и я наивно полагал, что так и продолжится. Но нет.

    Возможности бэкенда, вторая часть курса, показали мне, что из Питона можно сделать огромный веб-фреймворк, которым еще нужно научиться управлять. Получается, что это язык внутри языка. Да, логический синтаксис тот же самый, но все остальные команды — совсем другой разговор. Под конец этой главы нам еще и дали в финальном задании новую концепцию — представления, основанные на классах. Понять ее было очень не просто, но она действительно сильна и помогает ускорить разработку.

    Третья часть была по API. На мой взгляд, эта тема наравне с вводной частью по сложности. А вот интересности ей не занимать. Подключаться к внешним сервисам, получать информацию, обрабатывать ее, делать ботов — мечта, а не профессия.

    Дальше, к сожалению, не все так весело было. Алгоритмы и структуры данных в курсе были поданы очень вяло, а теория была совершенно не применима в практике. Объясняют рекурсию, дают задачу, ты решаешь ее рекурсией и не можешь уложиться в заданные параметры по памяти и времени. В итоге большинство задач решались лишь определенными алгоритмами и похоже это было скорее на олимпиаду, чем на обучение. После сдачи этой части я прочел самостоятельно книгу «Грокаем алгоритмы» и понял гораздо больше, чем дал Практикум. Говорят, эти главы переписывают и даже уже переписали, но факт остается фактом — часть слабая.

    Пятая глава обучения началась очень хорошо, заинтересовала серверами и докером, но в какой-то момент у авторов кончились силы и дальше пошло лишь «вставьте это в командную строку» и «смотрите, все получилось». Почему получилось? Что за параметры у команды были? Здесь у меня произошел переломный момент. Я начал докапываться до сути. Я составил список вопросов, пришел на вебинар и целый час выяснял у наставника как это все работает. Получил ответы, пошел их применять и опять начались несостыковки. Но тема докера меня всегда привлекала, и я решил разобраться. Так на этом сайте родилась серия статей про деплой, я прочитал всю документацию, придумал несколько способов сделать деплой, с каждой статьей улучшал свои познания и в какой-то момент постиг дзен. Докер стал для меня настолько родным, что я начал с удовольствием помогать однокурсникам и объяснять им, почему и как именно у них не работали проекты. Сложная глава, но по ней у меня самые лучшие знания остались.

    Шестая глава — дипломный проект. По началу все казалось достаточно простым, но потом выяснилось, что предоставленный нам фронтент был написан без DRY подхода — там постоянно и везде повторялся один и тот же код не только в HTML, но и в JavaScript и CSS. Это невероятно усложнило понимание и так не самой ясной для нас технологии. А на этапе оживления формы я вообще был готов сдаться — нас не просто учили другому, нам даже банально не объяснили как объект формы выглядит изнутри. Какое-то невероятное усилие и обратный инжиниринг все-таки помогли мне справиться с формой, дальше уже было легче. Но я твердо понял, что на факультет фронтента Практикума я не пойду, если там допустили такое.

    Сейчас я сдал дипломный проект и жду выпускного. Безусловно, я безумно рад, что не сдался, что 9 месяцев был на одной волне со своим курсом в сто с лишним человек. Яндекс.Практикум помог с пониманием маршрута по знаниям и в половине случаев эти знания дал. В другой половине — помогла документация и одногруппники.

    Формат вебинаров мне показался абсолютно бестолковым. Любую тему можно в два-четыре раза быстрее познать на Youtube, чем от наставников, да и буду честен — речь у них плохо поставлена, много слов-паразитов и в основном не очень адекватная подготовка к занятию. Вторую половину курса я вебинары не смотрел.

    Чего не хватает — так это списка литературы, а точнее ссылок на нужную документацию к заданиям, на видеоуроки, на статьи на тему, да даже на Stackoverflow. Понятно, что нужно учиться самому искать, но при объяснении темы нужно дать максимально адекватный перечень дополнительных материалов.

    Я долго думал, чем я займусь дальше. Многие уже ищут работу, но я решил познать как можно больше про технологии фронтенда, про JavaScript и фреймворки, основанные на нем. А также знакомый разработчик дал мне список технологий, которые нужно знать и понимать в современном мире. О них я расскажу в будущих статьях на этом сайте, подписывайтесь на обновления.

  • Docker-compose для разработки: видим изменения на лету

    Docker-compose для разработки: видим изменения на лету

    Docker-compose — невероятно мощный инструмент не только для деплоя в продакшине, но и для разработки. Для максимального удобства концептуально нам нужно применить в нем всего один прием — заменить тома на папки. Таким образом, наш проект будет иметь прямой доступ к хостовой машине и любые правки, которые мы будем вносить, будут в реальном времени отображаться в контейнерах.

    Давайте рассмотрим код-пример:

    version: '3.8'

volumes:
  postgres_data:

services:
  db:
    image: postgres:12.4
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    env_file:
      - ./.env
  django:
    build: .
    depends_on:
      - db
    restart: always
    env_file:
      - ./.env
    volumes:
      - .:/code/
    entrypoint: /code/entrypoint.sh

  nginx:
    image: nginx:1.19.0-alpine
    ports:
      - "127.0.0.1:1111:80"
    volumes:
      - ./static:/code/static
      - ./media:/code/media
      - ./nginx:/etc/nginx/conf.d/
    depends_on:
      - django
    restart: always

    Мы оставили на томе только базу данных. Все остальные данные вместо этого мы прикрепили к нужным папкам в нашем проекте.

    Смотрите, весь корень проекта в папке code, статика и медиа подключена напрямую к контейнеру nginx, как и его конфиг. Вот как он выглядит:

    upstream djangodocker {
    server django:8000;
}

server {

    listen 80;

    location / {
        proxy_pass http://djangodocker;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }
    location /static/ {
        alias /code/static/;
    }

    location /media/ {
        alias /code/static/;
    }

}

    Описание того, что здесь происходит, можно найти в статье про docker-compose. Там же вы увидите разбор entrypoint.sh:

    #!/bin/sh

sleep 2
python manage.py migrate
python manage.py createcachetable

if [ "$DJANGO_SUPERUSER_USERNAME" ]; then
  python manage.py createsuperuser \
    --noinput \
    --username "$DJANGO_SUPERUSER_USERNAME" \
    --email $DJANGO_SUPERUSER_EMAIL
fi

python manage.py collectstatic --noinput
gunicorn foodgram.wsgi:application --bind 0.0.0.0:8000

exec "$@"

    Тут добавлено автоматическое создание суперюзера, удобный в разработке момент. Для этого нужно добавить пару переменных в .env:

    DB_ENGINE=django.db.backends.postgresql # указываем, что работаем с postgresql
DB_NAME=postgres # имя базы данных
POSTGRES_USER=postgres # логин для подключения к базе данных
POSTGRES_PASSWORD=postgrespostgres # пароль для подключения к БД (установите свой)
DB_HOST=db # название сервиса (контейнера)
DB_PORT=5432 # порт для подключения к БД
SECRET_KEY=SECRET_KEYSECRET_KEYSECRET_KEY
DJANGO_SUPERUSER_PASSWORD=12345678
DJANGO_SUPERUSER_EMAIL=example@example.com
DJANGO_SUPERUSER_USERNAME=admin

    Чтобы новая установка Django подключилась к Postgres — измените настройки подключения в файле settings.py:

    DATABASES = {
    'default': {
        'ENGINE': os.environ.get('DB_ENGINE'),
        'NAME': os.environ.get('DB_NAME'),
        'USER': os.environ.get('POSTGRES_USER'),
        'PASSWORD': os.environ.get('POSTGRES_PASSWORD'),
        'HOST': os.environ.get('DB_HOST'),
        'PORT': os.environ.get('DB_PORT'),
    }
}

    И не забудьте, что для работы базы данных вам нужна зависимость:

    pip install psycopg2-binary

    Еще один важный момент — это изменения в файле Dockerfile. Теперь нам не нужно копировать весь проект на контейнер, мы и так туда подключим всю папку, но предварительная установка зависимостей и старт контейнера зависят от двух файлов, которые уже должны быть в контейнере:

    FROM python:3.9-slim

ENV PYTHONDONTWRITEBYTECODE 1

ENV PYTHONUNBUFFERED 1


WORKDIR /code
#COPY . /code
COPY ./requirements.txt /code
COPY ./entrypoint.sh /code
RUN pip install -r /code/requirements.txt


ENTRYPOINT ["/code/entrypoint.sh"]

    После этого вы просто запускаете команду docker-compose up и получаете рабочий прототип проекта на своей машине, со статикой:

    И что самое важное, вы сможете вносить изменения на лету и тут же их видеть!

    Отдельное спасибо за идею с прямым подключением файлов Leon Sandøy в его репозитории Django-Starter. Добавил сюда nginx и автоматическое применение миграций.

  • Django, Postgres, Nginx с помощью Docker-Compose

    Django, Postgres, Nginx с помощью Docker-Compose

    В настоящем руководстве описан механизм автоматического деплоя трех контейнеров на локальный сервер. Контейнер с django проектом будет раздавать логику с помощью Gunicorn, контейнер с nginx будет раздавать статику и осуществлять так называемую reverse-proxy на Gunicorn для логики, контейнер с базой данных Postgres будет работать с настройками по умолчанию.

    Важные аспекты деплоя

    1. Контейнеры зависимы друг от друга, сначала запускаем базу данных, затем приложение, последним — nginx
    2. При создании контейнеров с помощью docker-compose они автоматически объединяются в локальную сеть.
    3. Выход из этой сети будет один и только один — это открытый порт контейнера nginx,
    4. Остальные контейнеры не будут иметь связей с портами хостовой машины, что, в целом, не мешает им открывать порты внутри той самой локальной сети, созданной docker-compose. Делают они это неявно, и конкретные порты, как правило, можно найти в документации к используемому образу
    5. Стандартный порт, где доступна база данных — 5432
    6. Стандартный порт, где доступен Gunicorn — 8000

    Volumes — Тома

    Нам понадобится 4 тома для хранения следующей информации: база данных, статика, медиа файлы, конфигурация nginx. Объявим их сразу за версией docker-compose:

    version: '3.8'

volumes:
  postgres_data:
  static:
  media:
  nginx_conf:

    Контейнер 1: База данных

    Если внимательно прочитать документацию образа Postgres на Docker Hub, то можно выяснить, что контейнер этот легко запустить без каких либо дополнительных инструкций, главное, чтобы в наших переменных окружения был закрытый список необходимых для деплоя значений. Здесь мы используем одну маленькую, но очень удобную хитрость: мы используем одинаковые переменные окружения для контейнера с базой данных и контейнера с приложением django, где описано подключение к базе данных. Вот список:

    DB_ENGINE=django.db.backends.postgresql # для Django
DB_NAME=postgres # для Django и Postgres
POSTGRES_USER=postgres # для Django и Postgres
POSTGRES_PASSWORD=postgrespostgres # для Django и Postgres
DB_HOST=db # для Django
DB_PORT=5432 # для Django

    Таким образом, код для docker-compose получается следующим:

    services:
  db:
    image: postgres:12.4
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    env_file:
      - ./.env

    Указан образ, стоит ли перезапускать, если произойдет ошибка или сервер перезагрузится, путь к файлу базы данных внутри контейнера (это значение тоже из документации), а также откуда брать переменные окружения (в одной директории с docker-compose.yaml должен лежать файл .env).

    Наш контейнер теперь доступен только внутри сети из трех контейнеров по адресу db:5432

    Контейнер 2: Django и Gunicorn

    Так как Django раздает сам себя только в режиме debug=True, нам понадобится что-то более профессиональное, пусть этим займется Gunicorn. По умолчанию он раздает логику приложения на порту 8000, и нас это вполне устраивает, никаких дополнительных настроек здесь не требуется. Наш контейнер должен собраться только после того, как будет готова база данных. Как правило, скачивание образа, на котором будет построен ваш контейнер, занимает время, и за это время база уже построится и будет готова принимать соединения. Но при повторном деплое может произойти так, что база поднимется чуть позже, чем мы заходим применить стандартные наши команды: применить миграции и собрать статику. Поэтому в целях предотвращения этого я добавил в файл entrypoint.sh (который выполняется каждый раз при старте контейнера) инструкцию «подождать 10 секунд». Вот как выглядит код:

      django:
    image: matakov/yamdb:latest
    depends_on:
      - db
    restart: always
    env_file:
      - ./.env
    volumes:
      - static:/code/static
      - media:/code/media
      - nginx_conf:/code/nginx/
    entrypoint: /code/entrypoint.sh

    Забираем свежий образ, запускаем только после контейнера с базой данных, при падении — всегда перезапускаем, берем переменные окружения из файла .env, подключаем три тома:

    1. Статику в директорию со статикой
    2. Медиа файлы в директорию с медиафайлами
    3. Конфигурация Nginx берется их папки nginx. Тут есть важный момент. Наш контейнер с приложением должен первым забрать конфигурацию из этой папки и положить в свежесозданный образ. Если первым это сделает контейнер с nginx, то он подключит в образ свой конфиг по умолчанию, и он перезатрет (на самом деле не так, но для целей понимания будем говорить так) конфигурацию в нашем контейнере с приложением.

    Последняя инструкция запускает специальный файл каждый раз, когда контейнер стартует. Подробнее о проблемах, которые могут возникнуть с entrypoint.sh.

    entrypoint.sh

    #!/bin/sh

sleep 10

python manage.py migrate
python manage.py createcachetable
python manage.py collectstatic  --noinput
gunicorn api_yamdb.wsgi:application --bind 0.0.0.0:8000

exec "$@"

    Файл, который отслеживает подключение к базе данных, как только оно появляется, дает 10 секунд на то, чтобы все необходимые технические операции были завершены, затем мигрирует, создает кэш, собирает статику и, наконец, запускает Gunicorn на 8000 порту контейнера.

    Наш контейнер теперь доступен только внутри сети из трех контейнеров по адресу django:8000

    nginx.conf

    Чтобы наш сервер знал, как и с чем ему работать — нужно задать для него конфигурацию. Общая схема такая: на наш сервер на порт 80 приходит запрос, мы его проксируем на 80 порт контейнера с ngnix, он смотрит, если запрос на статику и медиа — отдает сам, а если запрос на логику — переадресовывает на контейнер с приложением на порт 8000. Приступим:

    upstream djangodocker {
    server django:8000;
}

server {

    listen 80;

    location / {
        proxy_pass http://djangodocker;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }
    location /static/ {
        alias /code/static/;
    }

    location /media/ {
        alias /code/media/;
    }

}

    Директива upstream позволяет нам дать название адресу с портом (что довольно удобно), а также дает возможность в будущем настроить здесь балансировщик нагрузки, просто добавив еще переменных server внутри upstream.

    Дальше стандартный раздел server:

    Слушаем 80 порт, если запрос пришел на главную страницу и все остальные, кроме статики и медиа, отправляем на наш контейнер django:8000, используя красивый upsteam-ярлык для этого djangodocker. Остальные строки просто передают также дальше и заголовки запросов.

    Обратите внимание на команды root- Это означает, что /static/ приклеится к пути /code/ и станет /code/static

    Команда alias в свою очередь указывает сразу на конечное расположение. Маленькая хитрость, лучше знать.

    Контейнер 3: Nginx

    Никаких особых настроек не требует, главное указать правильно пути до статики и медиа и нужную вам связь с внешним миром:

      nginx:
    image: nginx:1.19.0-alpine
    ports:
      - "80:80"
    volumes:
      - static:/code/static
      - media:/code/media
      - nginx_conf:/etc/nginx/conf.d/
    depends_on:
      - django
    restart: always

    Обратите внимание, контейнер зависит от django, поэтому конда он получит свой том nginx_conf — в нем уже будет лежать правильных конфиг, который мы написали выше.

    Если у вас на сервере уже есть сайт?

    Вы не можете в таком случае поднять свою сеть контейнеров на 80 порту, ведь он уже занят. В таком случае можно указать связку 8080:80, тогда ваше приложение будет доступно по ip:8080 в интернете. Если же вы хотите, чтобы оба сайта работали одновременно и на разных доменах, прочитайте статью про настройку веб-сервера Caddy и обязательно про безопасность открываемых портов.

    Далее — Continues Integration

    Разворачиваем приложение с помощью GitHub Actions

  • GitHub Actions: Как решить проблему entrypoint.sh: permission denied

    GitHub Actions: Как решить проблему entrypoint.sh: permission denied

    Некоторые проблемы возникают на ровном месте. И обычные способы решения не подходят. Вчера я увидел следующее сообщение при выполнении workflow на GitHub Actions:

    Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown

    Мы запускаем docker-compose, контейнеры начинают собираться и в момент, когда контейнер web решает запустить свой entrypoint (действие, совершаемое при каждом старте контейнера), мы получаем эту ошибку.

    Быстрый поиск нам дает понимание, что это проблема с разрешениями, и нужно просто выполнить классический набор команд, чтобы сделать файл исполняемым:

    chmod +x entrypoint.sh
git add entrypoint.sh
git commit

    Мы так и делаем, но проблема не уходит. Несколько часов поисков, везде один тот же рецепт. И вы даже с ним согласны, ведь когда вы просматриваете файлы командой:

    ls -la

    Вы видите, что исполнительный бит «х» добавился, и ну не может такого быть, чтобы он терялся по пути. А оказывается может. И теряется.

    В тот момент, когда мы делаем на Windows Git Bash команду git add, мы теряем исполнительный бит. Как до этого догадаться? Я поднял контейнеры без запуска entrypoint.sh и проверил его права, executive bit был потерян. Я начал искать его на виртуальной машине, которую создает GitHub Actions для деплоя и тоже не нашел его там. Тогда я догадался переформулировать поисковый запрос на…

    Git add lost executive bit

    Только такая формулировка дала мне правильный набор решений. Оказывается, именно под операционной системой Windows система контроля версий git может (но не всегда) терять исполнительный бит при добавлении в репозиторий. Решается это следующим набором команд:

    git add --chmod=+x -- entrypoint.sh
git commit

    То есть мы добавляем не файлу в операционной системе исполнительный бит, а файлу в момент присоединения его к коммиту.

    Решение не помогло? Замените CRLF на LF

    Есть еще одна особенность, которая может повредить исполняемые bash-файлы — это окончания строк. В среде Windows принято в конце строки ставить перевод каретки на следующую строку и в самое начало, и называется это дело CRLF.

    Естественно, в среде Linux все иначе, там перевод на начало строки не делают, только разрыв оставляют: LF. Проблема в том, что текстовые файлы по умолчанию в Windows используют несовместимые управляющие символы, и если вы хотите сделать ваш entrypoint.sh исполняемым — зайдите в настройки вашего любимого текстового редактора или IDE и установите параметр «Окончание строк» равным LF (Unix). Я лично рекомендую Notepad++ для этого:

    Надеюсь это маленькое расследование однажды сэкономит вам несколько часов времени.

  • Удаленный деплой с помощью docker-compose на GitHub Actions

    Удаленный деплой с помощью docker-compose на GitHub Actions

    Чем дольше знакомишься с темой, тем больше замечательных и простых вариантов находишь для выполнения своих задач. Деплой своего проекта — крайне обширная тема, и очень тяжело избежать ловушки мышления, когда пытаешь сделать на удаленной машине так же, как ты делаешь на своей.

    Допустим, как работает docker-compose? Ему необходим файл docker-compose.yaml, в котором описаны все контейнеры и их связи, а также от одного до бесконечности файлов Dockerfile, которые помогут собрать образы. Также всякие конфиги nginx, файлы с переменными окружения .env. И первое желание — перенести все эти файлы на удаленный сервер с помощью ssh или scp и начать разворачивать там руками.

    Но есть гораздо более правильный путь (This is the way). Наша задача копнуть чуть глубже и попробовать развернуть наши контейнеры на удаленном сервере без каких либо файлов в принципе. Не верите?

    Для начала нам нужно понять, что докер умеет гораздо больше, чем мы знаем. Например, он умеет управлять удаленным докером, установленным на нашем сервере. Для этого нам нужно создать так называемый контекст с настройками нашего удаленного сервера. По умолчанию у нас уже есть один контекст, он описывает подключение докера к нашей собственной машине, посмотрите на него:

    docker context ls

    Вы увидите этот слой с настройками, его имя default *, где астериск означает, что данный контекст (слой, файл с настройками) в данный момент активен.

    Если мы хотим создать новый контекст (опять-таки, для удобства думайте о нем как о файле с настройками), то нам нужно выполнить несколько условий:

    1. У нас должен быть приватный ключ SSH
    2. На сервере должен быть соответствующий ему открытый ключ
    3. Мы должны знать IP адрес сервера. Можно настроить и по домену, но, как показала практика, IP адрес дает более надежную идентификацию хоста
    4. Наш хост должен быть знаком нашему компьютеру, чтобы избежать лишних вопросов про то, доверяем ли мы ему

    Пункты в целом несложные, последний вообще можно исполнить без SSH подключения к серверу:

    ssh-keyscan -H 192.168.1.162 >> ~/.ssh/known_hosts

    Таким вот образом указанный выше IP будет с этого момента доверенным.

    Теперь давайте создадим новый контекст настроек. Типовая команда выглядит так:

    docker context create remote --docker "host=ssh://user@$host_ip"

    В данной строке есть команда create (создать), имя нашего нового контекста remote и хост, где работает Docker. Дело в том, что докер может управлять не только докером, но и целым swarm или Kubernetes. Это все системы оркестрации, где вы можете (как дирижер оркестра) управлять деплоем на сотни машин, про них позже, сейчас мы просто прокладываем мост между двумя докерами, самое простое решение, поэтому ключ пишем --docker.

    Попробуйте обязательно эту команду на своей локальной машине, указав удаленный хост. После этого у вас в списке контекста появится новый пункт — remote! Это значит, что теперь мы можем управлять нашей машиной на расстоянии, для этого нам нужно применить настройки этого контекста командой:

    docker context use remote

    Теперь * астериск будет стоять напротив пункта remote в списке контекстов. Не забудьте потом переключиться обратно на default, когда закончите.

    Ну что, проверим магию? Давай посмотрим список контейнеров на удаленном хосте командой…

    docker ps

    Именно! Все обычные команды, которые мы выполняли на локальной машине, подходят и теперь, только общаются они с удаленным сервером!

    Если у нас крутятся какие-то контейнеры, то давайте их все остановим и удалим, чтобы развернуть наш удаленный docker-compose. Раньше я предлагал ввести следующие команды:

    docker kill $(docker ps -q)
docker rm $(docker ps -a -q)

    Но этот способ слишком ультимативный. А если на сервере есть еще проекты? Ведь они все упадут. Поэтому новый вариант выглядит так:

              docker pull dockerhubname/image:latest
          docker-compose --context remote down
          docker volume rm foodgram-project_static

    Объясню, что здесь происходит. Мы стягиваем свежий образ нашего проекта с докерхаб, затем очень нежно выключаем наш проект с помощью встроенной в docker-compose функции down. Дальше я запускаю профилактическое удаление тома со статикой, так как она может обновиться в процессе разработки. В вашем случае нужно подставить правильное название тома, узнать его можно командой:

    docker volume ls

    Теперь самое время запустить docker-compose. Здесь важно понимать, что docker и docker-compose, несмотря на очевидное сходство в названии, по сути своей разные программы для выполнения разных задач. Раньше они вообще мало были связаны, сейчас интеграция становится все лучше и лучше. Совсем недавно docker-compose научился работать с контекстами docker, но пока это происходит не в автоматическом режиме после использования команды use, а с помощью специального флага —context. Перейдите в директорию с файлом docker-compose.yaml и выполните команду:

    docker-compose --context remote up -d --force-recreate

    Смотрите, мы используем контекст remote, поднимаем наши контейнеры в -d режиме (чтобы не видеть вывод) и на всякий случай силой их пересоздаем, если на сервере остались какие-то контейнеры с подобным названием. Все зависимости у нас под рукой — переменные окружения, yaml файл и прочие. Убедитесь, что все ваши контейнеры создаются на основе образов, а не собираются из файлов.

    В идеальном мире вы получите контейнеры, развернутые на вашем сервере. Проверьте, работает ли сайт по нужному адресу и порту.

    Справка по контексту доступна на сайте докера.

    GitHub Actions

    Как нам применить эти знания к деплою проекта с помощью GitHub Actions?

    Алгоритм будет следующий:

    1. Создаем виртуальную машину
    2. Разворачиваем наш репозиторий (можно не ставить зависимости, нам нужны только файлы): actions/checkout@v2
    3. Устанавливаем Python 3.8: actions/setup-python@v2
    4. Устанавливаем наш SSH KEY в виртуальную машину и добавляем наш IP в доверенные хосты. Очень поможет вот этот action.
    5. Устанавливаем последнюю версию докера, чтобы она могла управлять всеми другими версиями докера, в том числе и младшими (используйте sudo pip install docker-compose, в текущей версии по curl есть критический баг с OpenSSL и вы точно не хотите с ним провести пару часов)
    6. Создаем переменные окружения по инструкции
    7. Создаем пустой файл .env (почему-то без него docker-compose на сервере не может перейти к этапу просмотра переменных окружения в системе, на локальной машине таких проблем нет). Поможет команда touch .env
    8. Запускаем все наши команды из статьи выше, не забыв заменить секретные данные переменными окружения.

    Вот и все. Получилось, что весь деплой уместился в 6 строчек, если не считать объявления переменных окружения и установки зависимостей.

  • Как передать переменные окружения GitHub Actions Secrets на удаленный сервер для docker-compose?

    Как передать переменные окружения GitHub Actions Secrets на удаленный сервер для docker-compose?

    Иногда самые сложные вопросы имеют самые легкие ответы. Когда мы работаем на локальной машине, нам проще всего взять наши переменные окружения (environment variables) из файла .env при работе с docker-compose. Но ведь в таком виде секреты передавать в репозиторий нельзя! Значит, мы в лучшем случае запишем туда .env.template, где перечислим переменные и, возможно, дадим им некоторые значения по умолчанию для примера.

    Очевидно, что сами секреты мы заведем в настройках репозитория, в разделе GitHub Secrets:

    Но как их дальше передать на сервер? Первое, что хочется сделать — сформировать на сервере .env файл неким скриптом, но есть путь гораздо проще и чище, давайте используем стандартную команду export, которая в командной среде может присваивать переменную окружения и хранить ее прямо в системе, без каких-либо файлов! Добавим GitHub Action следующего вида:

        runs-on: ubuntu-latest
    needs: set_up_env
    steps:
      - name: executing remote ssh commands to set env
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            export DB_ENGINE=${{ secrets.DB_ENGINE }}
            export DB_NAME=${{ secrets.DB_NAME }}
            export POSTGRES_USER=${{ secrets.POSTGRES_USER }}
            export POSTGRES_PASSWORD=${{ secrets.POSTGRES_PASSWORD }}
            export DB_HOST=${{ secrets.DB_HOST }}
            export DB_PORT=${{ secrets.DB_PORT }}
            export SECRET_KEY=${{ secrets.SECRET_KEY }}
            export DJANGO_SUPERUSER_PASSWORD=${{ secrets.DJANGO_SUPERUSER_PASSWORD }}
            export DJANGO_SUPERUSER_EMAIL=${{ secrets.DJANGO_SUPERUSER_EMAIL }}
            export DJANGO_SUPERUSER_USERNAME=${{ secrets.DJANGO_SUPERUSER_USERNAME }}

    Также можно на лету генерировать .env файл, если это то, к чему вы больше привыкли:

                echo DB_ENGINE=${{ secrets.DB_ENGINE }} > .env
            echo DB_NAME=${{ secrets.DB_NAME }} >> .env
            echo POSTGRES_USER=${{ secrets.POSTGRES_USER }} >> .env
            echo POSTGRES_PASSWORD=${{ secrets.POSTGRES_PASSWORD }} >> .env
            echo DB_HOST=${{ secrets.DB_HOST }} >> .env
            echo DB_PORT=${{ secrets.DB_PORT }} >> .env
            echo SECRET_KEY=${{ secrets.SECRET_KEY }} >> .env
            echo DJANGO_SUPERUSER_PASSWORD=${{ secrets.DJANGO_SUPERUSER_PASSWORD }} >> .env
            echo DJANGO_SUPERUSER_EMAIL=${{ secrets.DJANGO_SUPERUSER_EMAIL }} >> .env
            echo DJANGO_SUPERUSER_USERNAME=${{ secrets.DJANGO_SUPERUSER_USERNAME }} >> .env

    Возможно, здесь много повторяющего кода, и хотелось бы записать это одной строкой с одним экспортом, но так, на мой взгляд, проще и понятнее. А также небольшая формула в экселе позволяет это довольно быстро сгенерировать:

    Теперь все переменные будут автоматически подставляться в docker-compose.

    env_file:
      - ./.env

    Которая, как известно, сканирует файл .env в поиске переменных. А все можно прочитать в документации:

    When you set the same environment variable in multiple files, here’s the priority used by Compose to choose which value to use:

    1) Compose file
    2) Shell environment variables
    3) Environment file
    4) Dockerfile
    5) Variable is not defined

    Сначала env файл, а затем уже переменные Shell. Это позволяет нам на компьютере для тестирования использовать один набор переменных, а для деплоя — другой.

  • Как извлечь docker-compose.yaml из образа на сервере?

    Как извлечь docker-compose.yaml из образа на сервере?

    В рамках Continuous Integration нам нужно уметь разворачивать не только контейнеры командой docker, но и группу контейнеров, например django + postgres + nginx.

    На локальной машине это просто, команда docker-compose up -d выполнит все инструкции из файла docker-compose.yaml, но на сервере его нет.

    Существует два способа доставить файл docker-compose.yaml на удаленный сервер. Мы не будем рассматривать вариант «доставить руками», ведь у нас непрерывная интеграция, а значит на каждый коммит и пуш в репозиторий на GitHub наш проект после прохождения всех тестов должен развернуться самостоятельно на сервере.

    Вариант 1

    Используя CI на базе GitHub Actions, мы можем воспользоваться сторонним действием, которое позволяет нам подключиться к удаленному серверу и скопировать произвольный файл из репозитория, который предварительно развернут на сервере GitHub:

          - name: copy docker-compose.yaml file to remote
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_KEY }}
          passphrase: ${{ secrets.PASSPHRASE }}
          source: "./docker-compose.yaml"
          target: "./code/"

    Обратите внимание, в разделе GitHub Secrets вам нужно будет указать необходимые переменные. Если вы не используете пароль на ваш SSH KEY — просто не указываете эту строчку.

    Повторимся, копирует он с виртуальной машины GitHub, и для того, чтобы на ней были ваши файлы, необходимо перед этим действием выполнить команду сбора файлов:

          - name: Check out the repo
        uses: actions/checkout@v2

    Вариант 2

    Подключиться через SSH в GitHub Actions к серверу и достать нужный файл из образа, который мы скачаем с Docker Hub:

          - name: executing remote ssh commands to deploy
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            sudo docker pull ${{ secrets.DOCKER_USERNAME }}/yamdb:latest
            id=$(docker create ${{ secrets.DOCKER_USERNAME }}/yamdb:latest)
            sudo docker cp $id:code/docker-compose.yaml docker-compose.yaml
            sudo mkdir nginx
            sudo docker cp $id:code/nginx/Dockerfile nginx/Dockerfile
            sudo docker cp $id:code/nginx/nginx.conf nginx/nginx.conf
            sudo docker rm -v $id

    Давайте разберем, что происходит. Вы подключаетесь по SSH, скачиваете ваш образ, дальше вы создаете временный контейнер из этого образа и кладете его имя в переменную id.

    Следом идут обычные команды копирования из контейнера на хостовую машину. Мы берем файлы для docker-compose, в том числе настройки nginx, а затем удаляем ненужный нам контейнер. Все, заключительным действием мы на всякий случай выключим и удалим все контейнеры (если это не первый наш деплой, то действие поможет избежать конфликтов) и запустим наши контейнеры:

                docker kill $(docker ps -q)
            docker rm $(docker ps -a -q)
            sudo docker-compose up -d --force-recreate

    Обратите внимание на флаг -d в последней команде — если его забыть, то логи докера никогда не закончатся и ваш CI никогда не завершится успешно.

  • SSL и открытые порты в Docker — как защитить соединение?

    SSL и открытые порты в Docker — как защитить соединение?

    В случае, когда за SSL сертификаты для докеризированных приложений отвечает внешний веб-сервер (например, Caddy), нужно очень внимательно отнестись к тому, как вы открываете порты в своем docker-compose.

    Обычная практика такая:

      nginx:
    build: ./nginx
    ports:
      - 8888:80
    volumes:
      - static_sp2:/code/static
      - media_sp2:/code/media
    depends_on:
      - web
    restart: "on-failure"

    Но здесь есть серьезная проблема. Ваш nginx теперь доступен не только по адресу localhost или 127.0.0.1, но и всему миру, если у сервера есть публичный адрес.

    Мы же выпускаем сертификат с помощью Caddy, значит доступ к сайту будет защищен только если пользователь придет по доменному имени. А что если он забьет ip адрес и добавить в конце порт 8888? Так он получит доступ к сайту без SSL, и может воспользоваться данной возможностью множеством неприятных способов.

    Поэтому мы будем создавать контейнеры правильно, мы будем их показывать только приложениям, которые крутятся на нашем сервере:

      nginx:
    build: ./nginx
    ports:
      - "127.0.0.1:8888:80"
    volumes:
      - static_sp2:/code/static
      - media_sp2:/code/media
    depends_on:
      - web
    restart: "on-failure"

    Обратите внимание, что с появлением локального айпи адреса нам пришлось взять все выражение в кавычки, иначе докер не сможет достойно распарсить данную строку.

    Смотрим, что показывает нам nmap:

    user@server:~$ nmap 127.0.0.1
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-24 06:42 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
5000/tcp open  upnp
5432/tcp open  postgresql
8000/tcp open  http-alt
8888/tcp open  sun-answerbook

    Видим, что внутри порт 888 открыт. Сканируем порты по внешнему доменному имени:

    matakov@matacoder:~$ nmap site.ru
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-24 06:44 UTC
Nmap scan report for site.ru (178.154.254.176)
Host is up (0.0011s latency).
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

    Все, уязвимость ушла, наружу смотрит только SSH, HTTP и HTTPS.

  • Простой SSL сертификат на базе веб-сервера Caddy, Django и Gunicorn

    Простой SSL сертификат на базе веб-сервера Caddy, Django и Gunicorn

    В рамках учебного проекта мне потребовалось развернуть на одном сервере два приложения. Первое из них — классический Django Framework, который крутится с помощью Guncorn, файлы лежат прямо на сервере. Второе же хитрое — полностью докеризированная связка Nginx + Gunicorn + PostgreSQL.

    Поднять незащищенное соединение совсем не сложно, у нас наружу светятся два порта, один от Gunicorn, один от Nginx из докера. Но как защитить все это дело? Если для серверного приложения с помощью Certbot это делается легко, то для докера настройки связки Certbot в контейнере и Nginx в контейнере — занятие не для слабонервных. А для того, чтобы сертификат заработал, нам потребовалось бы еще и пробрасывать 443 порт на докер, а сделать это можно двумя способами — либо не расшифровывая трафик через stream директиву Nginx, либо расшифровывая, но придется указать пути до ключей и, что самое сложное, понадобиться дать certbot положить файл в корневую директорию сайта для проверки соединения, а она у нас благодаря гуникорну не так-то просто достижима.

    В качестве решения можно использовать сервер Caddy. Идея будет заключаться в том, что за все сертификаты будет отвечать только она, за ней уже пойдет незашифрованный трафик до нужных нам портов.

    Установить Caddy просто, несколько команд в баше: 

    sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https 
    curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo apt-key add - 
    curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee -a /etc/apt/sources.list.d/caddy-stable.list 
    sudo apt update sudo apt install caddy

    Дальше необходимо создать конфиругацию. У кадди есть особенность, файл конфига может лежать где угодно. Я оставил его в домашней директории, он должен быть назван Caddyfile. Вот содержимое:

    site-1-on-server.ru {
    root * /home/user/site/
    @notStatic {
    not path /static/*
    not path /media/*
    }
    reverse_proxy @notStatic 127.0.0.1:8000
    file_server
    }
    site-2-in-docker.ru {
    reverse_proxy localhost:8888
    }

    Этот конфиг позволяет запустить сайт1, который у нас лежит на сервере в указанной папке. Директива notStatic создает исключения для Кадди, эти файлы она не будет отправлять в Gunicorn и будет сама обслуживать. Обратный прокси — стандартная как для Ngnix, так и для Кадди операция, мы передаем все запросы дальше, на 8000 порт Гуникорна.

    Вторая часть конфига не делает каких-либо исключений для статики, так как у нас в контейнерах крутится Nginx и он ответственный за статику.

    А теперь немного магии от Кадди. Когда мы в директории, где у нас каддифайл лежит, запустим команду sudo caddy start, она автоматически выпустит SSL сертификаты для обоих доменов и будет их обновлять, проверяя оставшееся время каждые 10 дней. То есть самая сложная часть в случае с приложением, которое лежит на сервере — указать пути до статики, а если поднимается докеризированное приложение — то всего две строки и готово.