Запуск Elasticsearch и Kibana в Docker Compose

docker-compose.yml

version: '3.9'

services:

  elasticsearch:
    build: ./build-elasticsearch
    container_name: elasticsearch
    restart: always
    environment:
      - "discovery.type=single-node"
    ports:
      - "9200:9200"
    networks:
      - es01

  kibana:
    build: ./build-kibana
    container_name: kibana
    restart: always
    environment:
      - SERVER_NAME=kibana
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200/
    links:
      - "elasticsearch"
    ports:
      - "5601:5601"
    networks:
      - es01

networks:
  es01:

Файл располагается в корневом каталоге.

Dockerfile для Elasticsearch

FROM docker.elastic.co/elasticsearch/elasticsearch:7.8.0

Файл располагается в ./build-elasticsearch.

Dockerfile для Kibana

FROM docker.elastic.co/kibana/kibana:7.8.0

Файл располагается в ./build-kibana.

Подробнее можно почитать на официальных страницах:

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

docker-compose up --build -d

Запуск Mongo и Mongo Express в Docker Compose

docker-compose.yml

version: '3.9'

services:
  
  mongo:
    build: ./build-mongo
    container_name: mongo
    restart: always
    networks:
      - mongo
    ports:
      - "27017:27017"
    environment:
      - MONGO_INITDB_ROOT_USERNAME=${MONGO_ROOT_USER}
      - MONGO_INITDB_ROOT_PASSWORD=${MONGO_ROOT_PASSWORD}
      - MONGO_INITDB_DATABASE=test-database

  mongo-express:
    build: ./build-mongo-express
    container_name: mongo-express
    restart: always
    networks:
      - mongo
    ports:
      - "8093:8081"
    environment:
      - ME_CONFIG_MONGODB_SERVER=mongo
      - ME_CONFIG_MONGODB_PORT=27017
      - ME_CONFIG_MONGODB_ENABLE_ADMIN=true
      - ME_CONFIG_MONGODB_ADMINUSERNAME=mongo
      - ME_CONFIG_MONGODB_ADMINPASSWORD=mongo
      - ME_CONFIG_MONGODB_AUTH_DATABASE=admin
      - ME_CONFIG_MONGODB_AUTH_USERNAME=${MONGO_ROOT_USER}
      - ME_CONFIG_MONGODB_AUTH_PASSWORD=${MONGO_ROOT_PASSWORD}
      - ME_CONFIG_BASICAUTH_USERNAME=${MONGOEXPRESS_LOGIN}
      - ME_CONFIG_BASICAUTH_PASSWORD=${MONGOEXPRESS_PASSWORD}

networks:
  mongo:

Файл располагается в корневом каталоге.

Файл .env:

MONGO_ROOT_USER=mongo
MONGO_ROOT_PASSWORD=mongo
MONGOEXPRESS_LOGIN=mongo
MONGOEXPRESS_PASSWORD=mongo

Dockerfile для Mongo

FROM mongo:5.0

Файл располагается в ./build-mongo

Dockerfile для Mongo Express

FROM mongo-express:0.54

Файл располагается в ./build-mongo-express

Подробнее можно почитать на официальных страницах:

docker-compose up --build -d

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

Запуск RabbitMQ в Docker Compose

docker-compose.yml

version: '3.9'
services:
   rabbitmq:
      build: ./build
      container_name: rabbitmq
      environment:
       - RABBITMQ_ERLANG_COOKIE=SWQOKODSQALRPCLNMEQG
       - RABBITMQ_DEFAULT_USER=rabbit
       - RABBITMQ_DEFAULT_PASS=rabbit
      ports:
       - "15672:15672"
       - "5672:5672"

Файл располагается в корневом каталоге.

Dockerfile

FROM rabbitmq:3-management
COPY ./conf/enabled_plugins /etc/rabbitmq/enabled_plugins

Файл располагается в ./build

enabled_plugins

[rabbitmq_management, rabbitmq_management_visualiser].

Файл располагается в ./conf/enabled_plugins

Подробнее можно почитать на официальной странице Docker Hub — RabbitMQ.

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

docker-compose up --build -d

Введение в контейнерную виртуализацию Docker

Вы работали с виртуальными машинами? Oracle VM VirtualBox, например? VirtualBox — это гипервизорная виртуализация, т.е. вы под основной ОС запускаете несколько программных эмуляций железа, на которых крутятся произвольные «гостевые» ОС (Linux, Windows, Mac OS, FreeBSD, вообще любые другие).

Это удобно, и для некоторых задач, незаменимо, но, как вы, наверное, понимаете, не слишком производительно. Очень много ресурсов тратится на эмуляцию: накладные расходы ОС и т.п.

Существует качественно иной подход к виртуализации — контейнерная. Это когда запущенно одно ядро ОС (обычно какой-то линукс) а вокруг него крутятся множество изолированных друг от друга юзерспейсов, каждый из которых для ползователя выглядит как отдельный хост.

Минусы в том, что ты можешь запускать только ОС которые могут работать с одним и тем же ядром (например RedHat и Debian или Ubuntu). К тому же изоляция не такая абсолютная как в гипервизорной виртуализации, т.е. если один хост словил панику ядра — лежат все.

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

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

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

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

В общем, интересная штука, которая может быть полезна многим.