Docker справочник cli

docker images — показать все локальные образы docker
docker rmi [-f] <id|label> — удалить образ c локальной машины
docker rmi -f $(docker images -q) — удалить все докер образы
docker build [-t <label>] <path> — построить образ на основе докерфайла
docker run [-dt] [--name <name>] [-v <path:path>] [-p <port:port>] [--...] <id|label> [cmd] — запустить образ в контейнере c cmd-командой (необязательно)
-d — в фоновом режиме
-t — прикрепляет к контейнеру терминал
-i — перенаправляет ввод/вывод на текущий терминал
--name — явно указать имя контейнера, по которому можно будет обращаться к нему (иначе будет сгенерировано рэндомно)
-p <external_port:internal_port> — проброс портов
-v --volume <external_path:internal_path> — монтирует папки хоста в контейнер
--rm — удаляет контейнер после завершения работы
--memory <n> — позволяет указать количество ОЗУ, доступной контейнеру
-P — пробрасывает все порты контейнера в хост-систему
--expose — позволяет пробросить несколько портов из контейнера в хост-систему
-e <"FOO=bar"> — добавляет переменную окружения в контейнер
docker ps [-a] — показать все запущенные [существующие] докер контейнеры
`docker ps -q | xargs docker stats —no-stream` — посмотреть ресурсы, потребляемые запущенными контейнерами
docker stop <name> — останавливает указанный образ (с сохранением данных)
docker kill <name> — то же самое без сохранения данных
docker rm <name> — удаляет указанный контейнер
docker attach <name> — подключиться к выбранному докер-контейнеру
docker exec [-ti] <name> <cmd> — выполняет команду в докер-контейнере
docker push <imagename> — отправить образ в удаленный реестр
docker ps -q | xargs docker stats --no-stream — посмотреть нагрузку на процессор и память каждого из контейнеров
docker stats — похожа на предыдущую команду, но более короткая
docker info --format '{{.LoggingDriver}}' — посмотреть используемый по умолчанию лог драйвер (json-file)
docker logs [<container_name>] [-f --tail 100] — показать логи [конкретного контейнера] в терминал [последние 100 строк]
docker inspect --format='{{.LogPath}}' <containername> -показать, где хранятся логи для конкретного контейнера

👉 @devops_star

Как работает Docker

👉 @devops_star

Нюансы Kubernetes

Контейнеризация и, в частности, Kubernetes – стандарт для запуска приложений в бою. Это несложно, но есть нюансы. Вместе с Андреем Новиковым из Evil Martians обсуждаем, что нужно сделать, чтобы приложение работало быстро и надежно. Смотрим, как работают requests и limits на ресурсы, чем должны отличаться liveness и readiness пробы и на что следует обращать внимание в мониторинге.

👉 @devops_star

Задаём порядок деплоя ресурсов в Kubernetes с помощью werf/Helm

При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, сначала нужно запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию/миграции БД, а уже затем запустить само приложение.

Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf.

https://habr.com/ru/companies/flant/articles/682804/

👉 @devops_star

Buildg - Интерактивный отладчик для Dockerfile, с поддержкой IDE (VS Code, Emacs, Neovim и т.д.).

Source-level inspection
Breakpoints and step execution
Interactive shell on a step with your own debugigng tools
Based on BuildKit (with unmerged patches)
Supports rootless

https://github.com/ktock/buildg

👉 @devops_star

Grafana OnCall — Open Source хаб для алертов и инцидентов

Если кратко, OnCall — это инструмент, который поможет организовать надежные оповещения/реагирование на инциденты в команде, соблюдать SLA и не просыпаться ночью от звонков.

OnCall — новичок в мире Open Source, но уже совсем не новичок как продукт. Он начался как отдельный SaaS под названием Amixr. IO несколько лет назад. Потом Amixr. IO приобрела Grafana Labs и интегрировала в свою экосистему. И вот недавно, наконец, мы смогли выложить исходный код OnCall в открытый доступ 🎉 А это значит, что он стал доступен большему кругу пользователей — и тем, кто работает в инфраструктуре без интернета, и тем, кто просто любит Open Source. Далее

https://habr.com/ru/articles/688794/

👉 @devops_star

Реальное собеседования DevOps инженер Junior++

Недавно мне знакомый прислал свое DevOps собеседование. Он DevOps инженер уровня Junior++. Опыт работы больше года. До этого работал сисадмином 2 года. Пришлось изменить голоса и убрать видео чтобы участников собеседования никто не узнал. А так же не узнал в какую компанию собеседовался Девопс инженер.

источник

👉 @devops_star

Haskell Dockerfile Linter

Интеллектуальный распаковщик Dockerfile, помогающий создавать лучшие образы Docker. Линтер разбирает Docker-файл на AST и выполняет правила поверх AST. Он опирается на поддержку ShellCheck для проверки Bash-кода внутри инструкций RUN.

https://github.com/hadolint/hadolint

👉 @devops_star

Настройка LDAP-аутентификации в кластере Kubernetes под управлением Deckhouse

Deckhouse — Kubernetes-платформа с открытым кодом, с помощью которой можно создавать идентичные Kubernetes-кластеры в любой инфраструктуре и автоматически управлять ими. Для проверки подлинности в Deckhouse используется модуль user-authn. Он настраивает единую систему аутентификации, интегрированную с Kubernetes и веб-интерфейсами других модулей — например, с Grafana.

user-authn поддерживает несколько внешних провайдеров и протоколов аутентификации: GitHub, GitLab, Bitbucket Cloud, Crowd, LDAP и OIDC. В статье расскажу, как развернуть сервер LDAP и настроить через него доступ к приложению.

https://habr.com/ru/companies/flant/articles/710010/

👉 @devops_star

Что такое MLOps? Самый подробный текст про работу с ML-системами, который вы найдете в интернете

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

Сохраняйте текст в закладки, потому что на данный момент это, возможно, самое полное описание MLOps на русском языке (и не перевод очередной англоязычной статьи!).

https://habr.com/ru/company/selectel/blog/703460/

👉 @devops_star

13 распространенных задач в Kubernetes и способы их решения

Команда VK Cloud перевела статью о проблемах в Kubernetes, с которыми часто сталкиваются инженеры-разработчики при запуске новых масштабируемых отказоустойчивых веб-сервисов.

https://habr.com/ru/companies/vk/articles/710852/

👉 @devops_star

5 приемов оптимизации сборки Docker-образов

Прием 1 — уменьшаем количество слоев в образе
Уменьшить количество слоев в образе можно сворачиванием нескольких однородных инструкций в одну. Например, несколько логически связанных инструкций RUN можно объединить в одну инструкцию с помощью конвейера Linux:

RUN apt-get update && apt-get install -y nginx



Прием 2 — удаляем ненужный кэш apt-get
Пакетный менеджер apt-get, обновляя репозиторий, сохраняет кэш, который в большинстве случаев не нужен, и его можно удалить, уменьшив тем самым собираемый образ на 100+ Мбайт. Сделать это совсем несложно, достаточно в инструкции RUN последней командой указать: && rm -f /var/lib/apt/lists/*.

Соединим оба приёма в одну инструкцию:

RUN apt-get update && apt-get install -y nginx && rm -f /var/lib/apt/lists/*
Такая конструкция работает именно в одной инструкции RUN, если вы вынесете rm -f /var/lib/apt/lists/* в отдельный RUN — ничего не сработает, так как кеш будет очищаться в другом слое, а его обновление будет оставаться в предыдущем слое.



Прием 3 — копируем только нужные файлы проекта в образ с помощью .dockerignore-файла
Обычно для копирования проекта в образ используется инструкция COPY с указанием места расположения проекта, как «.», что указывает на текущею директорию. Такой подход имеет один недостаток — будут скопированы все вложенные подкаталоги и файлы, что может значительно увеличить размер образа.

Исправить ситуацию призван .dockerignore-файл, который работает так же как и .gitignore-файл. В этих файлах указываются те папки и файлы, которые «не надо трогать». Gitignore-файл располагается в корневом каталоге копируемого в образ проекта. Обратите внимание на точку в начале названия файла — «.gitignore», так и должно быть.

Рассмотрим пример работы .gitignore-файла. Например, мы работаем с GIT, и в нашем проекте есть GIT-репозиторий. В образе он нам не нужен, поэтому его можно не копировать, а ещё в образе нам не нужен Dockerfile. Укажем эти файлы в .gitignore-файле:

.GIT
Dockerfile
При сборке образа Docker прочтет .dockerignore-файл и не включит в образ указанные в нем папки и файлы.


Приём 4 — используем минималистические Linux-образа Alpine
Как правило, для сборки образов применяются дистрибутивы Debian, Ubuntu, CentOS. Но это оправдано в том случае, если ваш проект будет использовать всё обилие возможностей ядра и пакетов, которые предоставляет выбранный дистрибутив. Если же вам нужно просто создать контейнер с Nginx или иной другой программой — используйте Alpine-сборки.

Alpine-образ весит считанные мегабайты, а не сотни Мбайт как Debian или Ubuntu, при этом в нём есть всё необходимое для запуска большинства приложений. Например, так выглядит dockerfile Nginx-образа на Alpine-сборке, который занимает 7 Мбайт:

FROM alpine
RUN apk add --no-cache nginx && mkdir -p /run/nginx
EXPOSE 80
COPY custom.conf /etc/nginx/conf.d
dockerCOPY . /opt/
CMD ["nginx”,”-g”,”daemon off;”]
Еще один бесспорный плюс Alpine — скорость сборки образа. Она разительно отличается в лучшую сторону по сравнению со скоростью сборки на любом другом дистрибутиве Linux.


Прием 5 — часто изменяемые слои ставим в конец dockerfile
Слоистая структура Docker-образов имеет одно неприятное свойство — при внесении изменения в один из слоев, это слой и все последующие слои будут пересобраны. Поэтому, чтобы сэкономить время на сборке образа — старайтесь ставить инструкции копирования кода проекта и конфигов в конец dockerfile до команды CMD или ENTRYPOINT.


👉 @devops_star