Docker-compose auto installation project?

Question

[Игорь]

Коллеги, добрый день!

Меня интересует вопрос.
Вопрос связан с автоматической установкой проекта.

Например, мне нужно передать проект кому-нибудь для дальнейшей разработки.
До этого было так, исполнитель ручками выполнял инсталляцию и настройку проекта.
Естественно всё это в docker-compose.

Хочу автоматизировать процесс.
Например вот так:

Power Shell (если линукс контейнеры под windows)

clear
echo "Starting installation..."
echo "---------------------------------"
docker-compose -f dc.dev.yml build
Start-sleep 1

echo ""
echo "Starting..."
docker-compose -f dc.dev.yml up -d
Start-sleep 1


# APP
echo ""
echo "Dependency installation..."
echo "---------------------------------"
docker exec -i rosinter.app composer install
Start-sleep 3

echo ""
docker exec -i rosinter.app php bin/console about
Start-sleep 5


echo ""
echo "Creating a database schema..."
echo "---------------------------------"
docker exec -i rosinter.app php bin/console doctrine:schema:create
Start-sleep 3


echo ""
echo "Restoring data from dump files..."
echo "---------------------------------"
docker exec -i rosinter.db sh -c 'exec mysql -uroot -prk3kw1UDdqOEF4L1pmNkcyQ2oL rosinter < var/mysql/dumps/dump.sql'

echo ""
echo "-------------------------------------"
echo "Installation completed successfully!"
echo "-------------------------------------"

На сколько верна стратегия, если ее можно так назвать?

Какой профит я хочу получить?
1. Я даю ссылку на репозиторий
2. Чувак скачивает проект
3. Запускает скрипт
4. Всё работает

Без дополнительных телодвижений.

Comments

[Игорь]

Хочу услышать мнение, кто уже подобное делал или как бы он сделал.

Answer 1

[Владимир Куц]

Лучше если это будут делать скрипты внутри контейнеров.
К примеру как стартует простой скрипт на Python

#!/bin/bash

VENV=./rvenv
# если нет виртуального окружения - создаем его
if [ ! -d $VENV ]; then
    virtualenv -p `which python3` $VENV
    $VENV/bin/pip install -U pip
fi

# устанавливаем/доустанавливаем нужные пакеты
$VENV/bin/pip install -r requirements.txt

# делаем миграции
$VENV/bin/python src/manage.py migrate

# ждем пока контейнер с фронтом соберет библиотеки с помощью webpack
sleep 5

while [ -f ./build_stat.flag ];
do
    sleep 1;
    echo "Wait for webpack"
done;

# собираем статику
$VENV/bin/python src/manage.py collectstatic --no-input


$VENV/bin/uwsgi --yaml ./src/uwsgi.yml

Comments

[Игорь]

Хм, но для разработки нужны volume на том хосте где установлена IDE например phpstorm.
То есть докер настраивается исключительно для разработки.

Лучше если это будут делать скрипты внутри контейнеров.

Чем отличается

echo ""
echo "Creating a database schema..."
echo "---------------------------------"
docker exec -i rosinter.app php bin/console doctrine:schema:create
Start-sleep 3

От внутреннего запуска?

[Владимир Куц]

Игорь, я привел пример старта сервиса на Python.
Докер используют для большей переносимости. Если мы будем прикручивать скрипт снаружи - то надо учитывать тонкости среды из-под которой мы запускаем.
К тому же в вашем примере вы указываете прямым текстом пароли базы:
'exec mysql -uroot -prk3kw1UDdqOEF4L1pmNkcyQ2oL rosinter'
А это не есть хорошо. При запуске внутренних скриптов - вы просто берет пароль из данных окружения. Что позволяет вам не хранить чувствительные к безопасности данные - к примеру - в репозитории проекта.

[Игорь]

Владимир Куц, То есть, в каждом контейнере запускаем нужный скрипт для инициализации проекта?

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

docker exec -i rosinter.app php bin/console doctrine:schema:create

В данном случае нужно что бы контейнеры были запущены

[Игорь]

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

Я пытаюсь понять, в какой степени моё решение верное.
Ну и не хотелось бы распыляться скриптами там сям.

Как в Windows
Setup.exe next > next > complete

[Владимир Куц]

То есть, в каждом контейнере запускаем нужный скрипт для инициализации проекта?

да

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

На примере питона - контейнер с Python зависим от контейнера с базой. Поэтому стартует база - а затем стартуем скрипт в контейнере Python
В Python в стартовом скрипте запускается миграция. Если были изменения - то эти миграции применяются, при этом создается схема базы, если не было таковой. Если же все изменения в базе есть - миграция выводит соответствующее сообщение, и выполнение стартового скрипта продолжается дальше.
Наверняка в php подобный механизм тоже есть.

[Игорь]

Владимир Куц, да, есть

[Владимир Куц]

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

[Игорь]

Вот проблема то.

если в докер файле сделать вот так

# Install dependencies
COPY composer*.json .
RUN composer install

То vendor на реальном хосте не появятся, как быть?
Они нужны для IDE и разработчику.

Dockerfile

FROM phpdockerio/php73-fpm

RUN mkdir -p www/

WORKDIR www/


# Install selected extensions and other stuff
RUN apt-get update \
    && apt-get -y --no-install-recommends install \
        php7.3-mysql \
        php-xdebug \
        php7.3-intl \
        php-yaml \
        php-curl \
        php7.3-gmp \
        curl \
        nano \
    && apt-get clean; rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*


# Install git
RUN apt-get update \
    && apt-get -y install git \
    && apt-get clean; rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*

# Composer
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
    && composer --version


# Install dependencies
COPY composer*.json .
RUN composer install

CMD [ "php-fpm7.3", "-F", "--pid", "/var/run/php-fpm7.3.pid" ]

docker-compose

# Php application
  app:
    container_name: rosinter.app
    restart: on-failure
    build:
      context: .
      dockerfile: ./docker/php/Dockerfile-dev
    volumes:
      - .:/www
      - ./docker/php/log:/var/log
    depends_on:
      - db
    links:
      - db
    expose:
      - 9000

[Владимир Куц]

Если vendor - это некое подобие виртуального окружения, которое нужно для вашего IDE и для запуска приложений внутри контейнера - то какая проблема просто иметь копию отдельно для IDE?
Поставили новый пакет при разработке у себя в IDE - добавили в composer*.json или куда там, и при следующем перезапуске контейнеров - скрипт их подтянет в контейнерах.

[Игорь]

Vendor это зависимости проекта.
Подтягивается при composer install

Если исполнитель выполнит это у себя на локальной машине, в 90% случаев у него не окажется требуемых расширений для php, да и самого php может быть у него нет.

Логично, что если настроить объёмы в docker-composer я должен был увидеть эту самую папку vendor, но ее нет.

И она не появится.

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