olafars

Уж не так все и просто, комрад ;)

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

Итого, у вас в группе проектов на GitLab (или в организации на GitHub) должно выйти примерно следующее:

/project-group (organization):
    /api - сюда можно вынести api вашего проекта.
    /desktop - здесь ваш web-проект для desktop на php, например.
    /mobile - здесь ваш web-проект для мобильной версии сайта, на той-же node.js.
    /admin - здесь ваша админка.
    /infrastructure - ну, или назовите проще, "server". Здесь ваши Dockerfile, docker-compose, ci/cd скрипты и т.п.

Чтобы моч варировать вашу инфраструктуру в зависимости от окружения, вы должны разделить репозиторий инфраструктуры на отдельные сервисы. Например, не все сервисы проекта должны запускаться в test окружении или на сервере тестовых веток на поддоменах, когда вы делаете домены вида "feature-1.test.project.com", чтобы ваши тестировщики могли тестировать фичи параллельно и независимо друг от друга. Так же, на dev и/или test окружениях может потребоваться сделать сервисы-заглушки на внешние api которые вы используете. Ну, например, на сервисы онлайн оплаты товаров на вашем сайте, которые будут отвечать всегда "OK" или не "OK".

Поэтому, чтобы можно было поднять среду с отличным от prod составом сервисов, нужно разделение.

Таким образом, в репозитории infrastructure должно получиться примерно следующее:

/infrastructure
   /api
       service.yml
       build.yml
       deploy.yml
   /mobile
       service.yml
       build.yml
       deploy.yml
   /desktop
       service.yml
       build.yml
       deploy.yml
   /admin
       service.yml
       build.yml
       deploy.yml
   /mysql
       mysql.cnf
       service.yml
   /redis
       redis.conf
       service.yml
   /php-fpm
       Dockerfile
       www-conf
       php.ini
       service.yml
   /nginx
       nginx.conf
       /prod
            site.conf
       /test
            site.conf
       /dev
            site.conf
   /cron
       Dockerfile
       crontab
       service.yml
mobile-dev.sh
desktop-dev.sh
prod.sh
test.sh

В этих самых *.sh файлах, что указаны выше, вы производите запуск нужного состава сервисов. К примеру, разработчику мобильной версии на react не обязательно покупать мощный ПК, чтобы на его машине запускать вообще весь проект, с mysql, redis, admin и другими сервисами. Вам будет достаточно собрать образ мобильного приложения, и написать в mobile-dev.sh примерно следующее:

docker-compose -f mobile/service.yml pull;
docker-compose -f mobile/service.yml down;
docker-compose -f mobile/service.yml up --detach;

Ну а в mobile/service.yml может быть что-то следующее:

version: "3.7"

services:
  mobile:
    image: keymetrics/pm2:10-alpine
    environment:
      APP_ENV: ${APP_ENV}
      APP_LANG: ${APP_LANG}
      API_URL: ${API_URL}
      BASIC_TOKEN: ${BASIC_TOKEN}
    working_dir: /app
    command: pm2-runtime start config.js --env $APP_ENV
    volumes:
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
      - ${APP_DIR}:/app
    restart: always
    container_name: mobile

API_URL при этом, можно приземлить на ваш тестовый или dev сервер. Таким образом, разработчик мобильной версии сайта будет иметь всегда ту версию api, которая по факту используется в проекте. Соответственно, код приложения должен уметь работать с переменными окружения для настройки своих параметров.

Ваш сайт - так же, должен запускаться отдельным service.yml файлом. Service.yml - можно поменять на docker-compose.yml в директории каждого сервиса, но, service здесь смотрится красивее.

Если требуется поднять все сервисы, необходимо передать последовательно все service.yml файлы через -f флаг вашему docker-compose. Это будет громоздкая команда, поэтому и делаются отдельные *.sh файлы для запуска.

Требуется понимать, что не следует хранить Dockerfile в репозитории каждого проекта, если наличие образа потребуется для этого проекта. Не каждый разработчик умеет делать Dockerfile и, например, устанавилвать расширения для PHP в рамках этих Dockerfile. Делегировав ответственность по сборке Dockerfile разработчикам проекта, вы рискуете получить неработающий сервис. Лучшее место для Dockerfile - в нашем примере, это репозиторий infrastructure, находящийся в распоряжении ваших DevOps-инженеров.

Та же история и с описанием build-процессов и процессов CI/CD. Не следует доаверять разработчику сборку его приложения в рамках целой огромной инфраструктуры проекта. Для этого в примере репозитория infrastructure - есть файлы build.yml/deploy.yml, в которых описана сборка и доставка сервисов. Любые CI/CD средства могут подключать фрагменты pipeline с внешних репозиториев, поэтому, когда у вас возникнет потребность сделать автобилд и автодеплой - проблем не будет, вы ведь уже учли все подводные камни совместной работы специалистов в вашей компании.

Прошу учесть следующее.

Выше описано, как правильно реализовать ваш проект на docker + docker-compose. Здесь не учтено наличие swarm-mode или kubernetes, тем не менее, данную структуру будет гораздо проще использовать в режиме swarm или c использованием kubernetes.

ЗЫ. Конечно, есть и другие рабочие практики на эту тему ;) Эта нравится мне больше всего, и работает универсальней остальных.

1. Как можно использовать ES6 в такой сборке, также перегонять файл server.js через babel или как?

ES2015 aka ES6 поддерживается полностью, кроме модулей. 2016+ — есть нюансы, смотря что нужно.
Использовать можно через хук.

2. Как nodejs/express можно будет использовать в связке с React/redux, какая структура проекта должна быть в таком проекте (1 или 2 packege.json должно быть и тп.)?

Зависит — если у вас изоморфное приложение, то все в одной директории, один package.json. Если классическое SPA, то можно и разделить, особенно если бэк и фронт будут разные люди делать.

Пара полезных ссылок: https://github.com/vmasto/express-babel
https://github.com/zeit/next.js

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

1. Что брать за базовый образ?
Что используете то и берите. Используете в работе Debian? Берите Debian ( https://registry.hub.docker.com/_/debian/ )
2. Чтобы создать свой базовый образ который будете в дальнейшем использовать для приложения, вот вам пример Dockerfile:

#
# MyBaseimage Dockerfile
#

# Pull base image.
FROM ubuntu:14.04

MAINTAINER Your Name <your.email@gmail.maybe>

RUN apt-get update
RUN apt-get upgrade -y

RUN apt-get install -y language-pack-en
ENV LANGUAGE en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LC_ALL en_US.UTF-8

RUN locale-gen en_US.UTF-8
RUN dpkg-reconfigure locales

RUN echo "Etc/UTC" > /etc/timezone
RUN dpkg-reconfigure -f noninteractive tzdata

RUN apt-get install -y build-essential
RUN apt-get install -y python python-dev python-setuptools python-pip python-virtualenv
RUN apt-get install -y libxml2-dev wget
RUN apt-get install -y libpcre3
RUN apt-get install -y libpcre3-dev
RUN apt-get install -y libssl-dev
RUN apt-get install -y libncurses5-dev
RUN apt-get install -y git git-core
RUN apt-get install -y libpq-dev

# install nginx
RUN apt-get install -y software-properties-common python-software-properties
RUN apt-get update

Собрать image в директории где у вас лежит Dockerfile

docker build -t your_docker_account/your_baseimage .

3. Dockerfile для сборки вашего образа уже с приложением

#
# MyApp Dockerfile
#

# Pull base image.
FROM your_docker_account/your_baseimage

MAINTAINER Your Name <your.email@gmail.maybe>

# Set instructions on build.
RUN virtualenv /env
ADD ./ /code

RUN cd /code; /env/bin/python setup.py install
RUN cp /code/config/config.yml.docker_example /etc/code/config.yml

# Expose ports.
EXPOSE 8484
WORKDIR /code
CMD ["/env/bin/python", "app.py"]

4. Собрать образ с приложением

docker build -t your_docker_account/your_app_container .

5. Запустить контейнер с БД, в качестве примера PostgreSQL

docker run -p :5432:5432 --name my_postgresdb_container -e POSTGRESQL_DB=mydb_name -e POSTGRESQL_USER=mydb_user -e POSTGRESQL_PASS=super_secret_password -d kamui/postgresql

для mariadb аналонично, контейнеры ищем здесь: https://registry.hub.docker.com/
6. Запустить контейнер с вашим приложением, пример:

docker run -d -p :5000:5000 \
  --name my_app_container \
  --link my_postgresdb_container:postgresdb \
  -e DOCKERDB_ENV_POSTGRESQL_DB=mydb_name \
  -e DOCKERDB_ENV_POSTGRESQL_USER=mydb_user \
  -e DOCKERDB_ENV_POSTGRESQL_PASS=super_secret_password \
  your_docker_account/your_app_container

7. Подключиться к запущенному контейнеру с приложением
docker exec -it your_app_container /bin/bash
8. Читать stdout запущенного приложения в контейнере
docker logs -f your_app_container

+ Чтобы автоматизировать запуск всех необходимых контейнеров берите Docker Compose ( https://docs.docker.com/compose/ )
Пример файла конфигурации:

your_app:
  build: .
  links:
    - postgresdb
  ports:
    - "5000:5000"
  environment:
    DOCKERDB_ENV_POSTGRESQL_DB: mydb_name
    DOCKERDB_ENV_POSTGRESQL_USER: mydb_user
    DOCKERDB_ENV_POSTGRESQL_PASS: super_secret_password
postgresdb:
  image: kamui/postgresql
  ports:
    - "5432:5432"
  environment:
    POSTGRESQL_DB: mydb_name
    POSTGRESQL_USER: mydb_user
    POSTGRESQL_PASS: super_secret_password

И теперь вместо пунктов 5 + 6 где мы запускали контейнеры мы можем всё стартануть одной командой
docker-compose up

+ можно смонтировать код в контейнер и разрабатывать непосредственно в docker'контейнере.
Надеюсь чем-то вам помог.

GNU coreutils
git.savannah.gnu.org/cgit/coreutils.git/tree
Это те самые ls, chown, uniq, с которыми люди сталкиваются каждый день работая в консоли. Множество маленьких "проектиков", обильно прокомментированных и уже хорошо оттестированных "на кроликах". Каждая конкретная утилитка выполняет маленькую понятную задачку, но в реальном коде вскрываются множество тонкостей, о которых в базовых учебниках не пишут, а знать надо.

Простенькие проекты:

• Программа, которая делает скриншот экрана и сохраняет его в bmp-файл.
  
• Проигрыватель mp3, ogg и wav-файлов.
  
• Приложение, снимающее вебкамерой фото и/или видео.
  
• Программа, записывающая звук с микрофона в wav-файл

Можно написать простой компилятор или интерпретатор.
Расширения на Си для Python говорят весёлая штука ^^

Если интересно низкоуровневое программирование, которое включает в себя доступ к оборудованию, то найдите любой гаджет (камера, роутер, телефон..) с прошивкой с открытым исходным кодом. Try hacking!

Если захотите полистать/поковырять действительно хороший код:

• SQLite - 50 оттенков чистого Си
  
• Unix утилиты, например, less.
  Just run this: apt-get source less

И наконец, попробуйте взглянуть на ядро Linux.
Конечно, это более 10 млн строк кода, но также оно чрезвычайно модульно и хорошо документировано. Есть две очень хороших книги на эту тему: Understanding the Linux Kernel и Linux Device Drivers (последняя находится в свободном доступе в Интернете).