wabat_microservices

wabat microservices repository

docker-1

docker format output

docker inspect <_id> выдает массив json, описывающий все параметры <u_container_id> или <u_image_id>

ключ --format= c другими опциями

docker использует go templates для форматирования вывода

docker-2

docker container

docker mashine - инструмент для управления машинами с dcoker

docker run --pid

по умолчанию PID namespace контейнера включен, ключ --pid используется для управления PID namespace контейнера, для включения в namespace другого контейнера или хоста на котором он запущен

namespaces

docker-3

Сбрка образов

Рекомендации

• создавать эфемерные контейнеры со statless приложениями
• использовать отдельные директории для build context
• использовать .dockerignore на манер .gitignore

Оптимизация размера

• не устанавливать не нужные пакеты
• использовать multistage builds
• собирать аргументы инструкции RUN

docker-4

Сети docker, docker-compose

Сети docker

типы сетевых драйверов:

• bridge (default)
• host
• none
• macvlan
• 3rd party

подробнее тут

docker-compose

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

по умолчанию docker compose читает два файла docker-compose.yaml и docker-compose.override.yaml, переопределить которые можно другими файлами следующими после ключа -f при старте, при этом каждый последующий будет переопределять предыдущий

считается что на каждую версию приложения нужно собирать образ заново

gitlab-ci-1

Устройство Gitlab CI. Построение процесса непрерывной интеграции

рекомендации по подбору сервера

в проекте может быть определен CI/CD пайплайн, задачи (jobs) входящие в пайплайн должны исполняться на runners, установку и регистрацию которых можно производить в ручную или автоматически, например при помощи ansible-gitlab-runner

настроить интеграцию со slack можно при помощи web-hook в Project > Settings > Integrations > Slack notifications

gitlab-ci-2

Непрерывная поставка с Gitlab CI

Схема непрерывной поставки:

1. сервера gitlab

2. runners (установленных локально на сервере gitlab)

• docker executor, с дефлтным базовым образом gitlab/gitlab-runner:latest, запускающим задания без тега
• shell executor, запускающий задания с тегом ansible в контейнере с установленным ansible; dockerfile

для работы с динамическими окружениями необходимо:

указать в ansible.cfg пользователя, приватный ключ, путь к инвентарному скрипту; ключи-ssh; файлы с учетными данными и скрипт gce.py монтируются к контейнеру к папке /etc/ansible/inventory;

3. ansible-playbooks:

• выполняющихся для создания/удаления инстансов
• выполняющиеся на созданных инстансах для установки среды и самого приложения (docker, git clone)

Файлы playbook находятся в директории gitlab-ci/continious-delivery/ansible-playbooks.

---

Схема реализована на основе Google Cloud Platform и динамического инвентарного скрипта gce.py. В vars.yml необходимо заполнить переменные:

из файла ключа Сервисные аккаунта в проекте GCE,

ключ-ssh для создаваемых инстансов,

а так же имя этого инстанса.

log data analyze

usful links

[grok template debug](https://grokdebug.herokuapp.com)

kubernetes-1

kubernetes-hard-way

repository contains ansible playbooks for automating all steps of Kubernetes The Hard Way tutorial.

Install and configure The Google Cloud SDK https://cloud.google.com/sdk/downloads.