Я не думаю, что на самом деле существует стопроцентно правильный или неправильный способ его использования: локальные сборки и настройки для разработчиков, как правило, имеют разные порой необычные требования, и поэтому стандарт не всегда соответствует реальности. Пожалуйста, отнеситесь к статье с соответствующим скептицизмом.
В любом случае, вот краткое изложение некоторых из кардинальных "грехов", которые я совершил при использовании docker-compose.
Как получаются контейнеры? Обычно из серии операторов, таких как RUN, FROM и COPY, которые помещаются в Dockerfile и собираются. Но как эти команды превращаются в образ, а затем в работающий контейнер? Понять это можно если пройти этапы создания образа контейнера самостоятельно. Мы создадим образ программно, а затем разработаем обычный синтаксический интерфейс и будем использовать его для создания образа.
Эта статья помогла мне немного углубится в устройство и принцип работы контейнеров. Поэтому решил ее перевести. "Экосистема контейнеров иногда может сбивать с толку, этот пост может помочь вам понять некоторые запутанные концепции Docker и контейнеров. Мы также увидим, как развивалась экосистема контейнеров". Статья 2019 года.
Docker - одна из самых известных платформ контейнеризации в настоящее время, она была выпущена в 2013 году. Однако использование изоляции и контейнеризации началось раньше. Давайте вернемся в 1979 год, когда мы начали использовать Chroot Jail, и посмотрим на самые известные технологии контейнеризации, появившиеся после. Это поможет нам понять новые концепции...
Когда говорят про DevOps обычно всегда подразумевают работу с Linux. Но есть большое количество решений под Windows. Как осуществлять сборку Windows c помощью Packer в своем блоге поделился Netflix (Джастин Фелпс и Мануэль Корреа - Applying Netflix DevOps Patterns to Windows). Предлагаю перевод статьи.
В Netflix настройка образов Windows происходило вручную, были ошибки и это был трудоемкий процесс. В этой статье мы описываем, как мы улучшили методологию, какие технологии мы использовали, и как это улучшило развертывание и согласованность сервисов.
В последнее время увлекаюсь Pythonом. Хотелось написать что-то более существенное, чем коды типа helloworld. Поскольку с интересом смотрел еще и в сторону ботов телеграмма, родилась идея создать бота, который бы запускал команды или скрипты на удаленном сервере (linux) и возвращал бы результат в телеграмм. Зачем? Удобно! Не надо логиниться на сервак, чтобы получить информацию о нагрузке на процессор, свободной памяти или объеме диска. Можно даже запускать скрипты.