Hello world docker

Hello Build

Estimated reading time: 7 minutes

Hello Build!

It all starts with a Dockerfile.

Dockerfiles are text files containing instructions. Dockerfiles adhere to a specific format and contain a set of instructions for which you can find a full reference in the Dockerfile reference.
Docker builds images by reading the instructions from a Dockerfile.

Docker images consist of read-only layers, each resulting from an instruction in the Dockerfile. Layers are stacked sequentially and each one is a delta representing the changes applied to the previous layer.

Dockerfile basics

A Dockerfile is a text file containing all necessary instructions needed to assemble your application into a Docker container image.

Here are the most common types of instructions:

Dockerfiles are crucial inputs for image builds and can facilitate automated, multi-layer image builds based on your unique configurations. Dockerfiles can start simple and grow with your needs and support images that require complex instructions.
For all the possible instructions, see the Dockerfile reference.

Example

Here’s a simple Dockerfile example to get you started with building images. We’ll take a simple “Hello World” Python Flask application, and bundle it into a Docker image that we can test locally or deploy anywhere!

Sample A
Let’s say we have the following in a hello.py file in our local directory:

If you test the example, make sure to copy over the indentation as well! For more information about this sample Flask application, check the Flask Quickstart page.

Sample B
Here’s a Dockerfile that Docker Build can use to create an image for our application:

This is our syntax directive. It pins the exact version of the dockerfile syntax we’re using. As a best practice, this should be the very first line in all our Dockerfiles as it informs Buildkit the right version of the Dockerfile to use. See also Syntax.

Initiated by a # like regular comments, this line is treated as a directive when you are using BuildKit (default), otherwise it is ignored.

# install app dependencies

Comments in dockerfiles begin with the # symbol. As your Dockerfile evolves, comments can be instrumental to document how your dockerfile works for any future readers and editors of the file.
See also the FROM instruction page in the Dockerfile reference.

This RUN instruction executes a shell command in the build context. A build’s context is the set of files located in the specified PATH or URL. In this example, our context is a full Ubuntu operating system, so we have access to its package manager, apt. The provided commands update our package lists and then, after that succeeds, installs python3 and pip, the package manager for Python.
See also the RUN instruction page in the Dockerfile reference.

RUN pip install flask

This second RUN instruction requires that we’ve installed pip in the layer before. After applying the previous directive, we can use the pip command to install the flask web framework. This is the framework we’ve used to write our basic “Hello World” application from above, so to run it in Docker, we’ll need to make sure it’s installed.
See also the RUN instruction page in the Dockerfile reference.

This COPY instruction copies our hello.py file from the build’s context local directory into the root directory of our image. After this executes, we’ll end up with a file called /hello.py inside the image, with all the content of our local copy!
See also the COPY instruction page in the Dockerfile reference.

This ENV instruction sets a Linux environment variable we’ll need later. This is a flask-specific variable, that configures the command later used to run our hello.py application. Without this, flask wouldn’t know where to find our application to be able to run it.
See also the ENV instruction page in the Dockerfile reference.

This EXPOSE instruction marks that our final image has a service listening on port 8000. This isn’t required, but it is a good practice, as users and tools can use this to understand what your image does.
See also the EXPOSE instruction page in the Dockerfile reference.

This CMD instruction sets the command that is run when the user starts a container based on this image. In this case we’ll start the flask development server listening on all hosts on port 8000.
CMD instruction page in the Dockerfile reference.

Test the example

Go ahead and try this example in your local Docker installation or you can use Play with Docker that provides you with a temporary Docker instance on the cloud.

To test this example:

Create a file hello.py with the content of sample A.

Create a file named Dockerfile without an extension with the contents of sample B.

Breaking down the docker build command:

So, in accordance with the build command issued and how build context works, your Dockerfile and python app need to be on the same directory.

From your computer, open a browser and navigate to http://localhost:8000 or, if you’re using Play with Docker, click on Open Port.

Other resources

If you are interested in examples in other languages, such as GO, check out our language-specific guides in the Guides section.

Источник

Docker: по ту сторону Hello World

В мире программирования существуют технологии, must have для каждого разработчика, к числу которых относится и Docker. Подразумевается, что это просто, как таблица умножения, и известно всем. О том, зачем в 2021 году в 100500й раз заводить разговор про докер — статья Сергея Кушнарева, руководителя отдела разработки ZeBrains.

С одной стороны — про него все знают. С другой — если тебя устраивают небольшие веб-проекты, особенно на какой-то конкретной CMS, то докер очень часто оказывается тем самым «первым лишним», и все сводится к инструкции «возьми готовый докер-файл, запусти в терминале docker run и будет тебе счастье». А когда понимаешь, что этого уже недостаточно — натыкаешься на статьи, написанные по тому же принципу «скачайте-запустите-получите». Кому этого мало — читайте дальше.

Зачем программисту холодильник

Кто сказал: «Не люблю пить теплое»? Убираем емкость подальше и смотрим на принципиальную схему девайса:

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

А теперь представим, что в доме программиста появилось существо противоположного пола, считающее, что в холодильнике можно хранить мясо. Что характерно — замороженное. Но при этом, как несложно догадаться, замерзнут до непотребного состояния и напитки, что нас в некотором смысле не совсем устраивает.

У нас два пути: купить второй холодильник или разделить тот, что у нас есть, на две камеры с датчиками температуры на входе, чтобы управлять клапаном подачи хладагента внутрь. Ура, мы только что изобрели двухкамерный холодильник. А заодно — разобрались с тем, для чего программистам понадобились виртуальные машины и докер.

Проекты, которые мы делаем, не сильно отличаются от продуктов в холодильнике — каждому нужны свои условия. Для одного — PHP 7.4, база MySQL 7.6, Sphinx и мейлер на Golang. Для другого — нода 12 версии, Angular 7 и база MySQL 8.0. Проектов может быть не один десяток. Установить это все на одну машину — все равно, что запихнуть все продукты в одну камеру холодильника.

Нужно как-то изолировать один проект (продукт) от другого. На помощь приходит или виртуальная машина (еще один холодильник), или докер (вторая камера со своими настройками). Давайте немного изменим схему нашего устройства:

Включаем воображение и смекалку, поехали!

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

В случае, когда мы физически разделяем холодильную и морозильную камеры (container engine), нам не нужна вторая розетка (hypervisor) и место для второго холодильника (полноценная Guest OS). Мы получили два независимых контейнера — каждый со своими условиями (bins/lib), которые подходят нужному продукту (app).

Что ты, черт возьми, такое, Докер?

Разделим вопрос на две части: «как с этим работать» и «как это работает». Эта статья посвящена ответу на первую часть. Если интересно углубиться в детали, пишите в комментариях — поговорим про изоляцию процессов, пространства имен и прочее. А может быть, напишу еще одну статью.

Из схемы выше очевидно, что ответ на вопрос «что такое докер» спрятан в блоке «Container/Docker engine», иначе говоря — движок контейнеризации. Давайте посмотрим на него внимательней:

Первым делом нам потребуется некий сервис (Docker daemon), который будет управлять всем процессом — набор инструкций, как создавать изолированные пространства. Поселим его на своем компьютере!

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

Неважно, какую операционную систему вы выберете — все равно выполнение произойдет на Linux. В Windows и Mac будет запускаться виртуализированное ядро Линукса для докера.

Для того, чтобы мы могли как-то управлять этим сервисом, воспользуемся REST API, а команды будем выдавать посредством CLI, назовем его для удобства клиентом (Docker client).

Сами приложения и нужные для их работы библиотеки мы будем хранить в виде файлов-образов (Docker-images). Можете воспринимать их по аналогии с ISO-образами DVD-дисков или как специфический вид архива с данными.

Чтобы все заработало, мы должны с помощью клиента попросить Docker daemon взять конкретный образ и развернуть его в работающий контейнер. Но откуда он его возьмет? Добавим немного логики и инфраструктуры — пусть Docker daemon создаст на нашем компьютере реестр образов и при запросе находит нужный. А если не нашел — отправляется в сеть, находит Docker Hub (сетевой реестр), находит там нужный образ и копирует к нам на локальный компьютер.

Указать, какой конкретно образ нам нужен, мы можем или при запуске контейнера из готового образа (docker run), или при создании нового образа (docker build), или просто запросив скачивание (docker pull).

Получив нужный образ, докер-демон запустит на его основе контейнер, и мы получим работающее приложение. Заодно докер пробросит внутрь изолированного контейнера сеть (network), чтобы мы смогли увидеть результаты работы приложения, и при необходимости «прикрутит» к нему хранилище для сохранения данных (data volumes).

Повторение — мать учения

Теперь все вышеизложенное — но на примере демонстрационного приложения Hello World. Считаем, что демона мы на своем компе уже поселили, ссылка на установку — чуть выше по тексту.

Выполняем команду docker run hello-world и видим следующий результат:

Первое что произошло после команды «докер, запусти образ с именем hello-world», это попытка найти его локально и запустить.

Попытка не увенчалась успехом (у меня была чистая установка докера), причем, обратите внимание, искался образ не hello-world, а hello-world:latest.
Через двоеточие указывается тег — что-то вроде версии или модификации образа. Если его не указать, будет искаться самая свежая версия с общепринятым тегом latest.

Тогда докер решает поискать этот образ на docker hub`е и скачать его оттуда.
https://hub.docker.com/_/hello-world

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

А далее видим следующие строки:

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

А именно — из только что скачанного образа был создан контейнер. Если перевести на язык ООП, создался объект sleepy_antonelli (контейнер) экземпляр класса hello-world (образа). Sleepy_antonelli — это рандомно сгенерированное имя контейнера, поскольку мы не указали его явно.

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

Собственно, это тут и написано (вместе с призывом не останавливаться на достигнутом и ссылкой на документацию). Но давайте проверим сами.

Если выполнить команду docker images, мы увидим скачанный образ.

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

«Людоеды — как лук, многослойные!»

Осталась еще одна тонкость, которую следует рассказать. Если образ неизменен, а контейнеры смертны, то тогда придется под каждую задачу создавать свой образ?

Нет, для этого придуманы слои. Каждое изменение образа можно выносить в отдельный слой. Это позволяет комбинировать их в разные итоговые образы. И вдобавок, уже готовый образ можно взять за основу и «наслоить» что-то свое.

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

Если выполнить предложенную команду из hello world:

То мы увидим, что там несколько слоев:

Подведем итоги

Что же дает нам докер? Во-первых, это изоляция — мы можем запускать что угодно на своем компьютере, не опасаясь за целостность как системы, так и приложения. Они просто не пересекаются.

Во-вторых — чистота. Образ на диске — это самые обычные «инертные» файлы, которые «оживают» только при создании контейнера. Контейнеры же изолированы от внешнего мира.

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

Наконец, это предсказуемость. Контейнеру все равно, что находится снаружи. Поэтому если ваше приложение работало в контейнере на вашем локальном компьютере, оно заработает на любом другом. Забудьте про dependencies hell — эта фраза дорогого стоит!

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

Вопросы, уточнения и комментарии можно оставлять прямо под текстом — буду рад пообщаться.

Источник

Полное практическое руководство по Docker: с нуля до кластера на AWS

Содержание

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

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

Что такое контейнер?

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

Виртуальные машины отлично подходят для полной изоляции процесса для приложения: почти никакие проблемы основной операционной системы не могут повлиять на софт гостевой ОС, и наоборот. Но за такую изоляцию приходится платить. Существует значительная вычислительная нагрузка, необходимая для виртуализации железа гостевой ОС.

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

Почему я должен использовать их?

Взлет Докера был по-настоящему эпичным. Не смотря на то, что контейнеры сами по себе — не новая технология, до Докера они не были так распространены и популярны. Докер изменил ситуацию, предоставив стандартный API, который сильно упростил создание и использование контейнеров, и позволил сообществу вместе работать над библиотеками по работе с контейнерами. В статье, опубликованной в The Register в середине 2014 говорится, что Гугл поддерживает больше двух миллиардов контейнеров в неделю.

Google Trends для слова ‘Docker’

В дополнение к продолжительному росту Докера, компания-разработчик Docker Inc. была оценена в два с лишним миллиарда долларов! Благодаря преимуществам в эффективности и портативности, Докер начал получать все больше поддержки, и сейчас стоит во главе движения по контейнеризации (containerization). Как современные разработчики, мы должны понять этот тренд и выяснить, какую пользу мы можем получить из него.

Чему меня научит это пособие?

Это единое и полное пособие по всем аспектам работы с Докером. Кроме разъяснения мифов о Докере и его экосистеме, оно позволит вам получит небольшой опыт по сборке и деплою собственных веб-приложений в облаке. Мы будем использовать Amazon Web Services для деплоя статичных сайтов, и два динамических веб-приложения задеплоим на EC2 с использованием Elastic Beanstalk и Elastic Container Service. Даже если вы никогда ничего не деплоили, это пособие даст вам все необходимое.

Как использовать этот документ

Этот документ содержит несколько разделов, каждый из которых посвящен определенному аспекту Докера. В каждом разделе мы будем вводить команды или писать код. Весь код доступен в репозитории на Гитхабе.

Введение

Внимание: В этом пособии используется версия Докера 1.12.0-rc2. Если вы столкнулись с несовместимостью, пожалуйста, отправьте issue. Спасибо!

Пре-реквизиты

Все, что нужно для прохождения этого пособия — это базовые навыки с командной строкой и текстовым редактором. Опыт разработки веб-приложений будет полезен, но не обязателен. В течение работы мы столкнемся с несколькими облачными сервисами. Вам понадобится создать аккаунт на этих сайтах:

Настройка компьютера

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

Докер

Проверим, все ли установлено корректно:

Python

Python обычно предустановлен на OS X и на большинстве дистрибутивов Linux. Если вам нужно установить Питон, то скачайте установщик здесь.

Мы будем использовать pip для установки пакетов для нашего приложения. Если pip не установлен, то скачайте версию для своей системы.

Для проверки запустите такую команду:

Java (не обязательно)

1.0 Играем с Busybox

Для начала, запустите следующую команду:

1.1 Docker Run

Отлично! Теперь давайте запустим Докер-контейнер с этим образом. Для этого используем волшебную команду docker run :

Ура, наконец-то какой-то вывод. В нашем случае клиент Докера послушно запустил команду echo внутри контейнера, а потом вышел из него. Вы, наверное, заметили, что все произошло очень быстро. А теперь представьте себе, как нужно загружать виртуальную машину, запускать в ней команду и выключать ее. Теперь ясно, почему говорят, что контейнеры быстрые!

Теперь виден список всех контейнеров, которые мы запускали. В колонке STATUS можно заметить, что контейнеры завершили свою работу несколько минут назад.

Вам, наверное, интересно, как запустить больше одной команды в контейнере. Давайте попробуем:

При удалении идентификаторы будут снова выведены на экран. Если нужно удалить много контейнеров, то вместо ручного копирования и вставления можно сделать так:

1.2 Терминология

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

2.0 Веб-приложения и Докер

2.1 Статические сайты

Давайте начнем с малого. Вначале рассмотрим самый простой статический веб-сайт. Скачаем образ из Docker Hub, запустим контейнер и посмотрим, насколько легко будет запустить веб-сервер.

Так как образа не существует локально, клиент сначала скачает образ из регистра, а потом запустит его. Если все без проблем, то вы увидите сообщение Nginx is running. в терминале. Теперь сервер запущен. Как увидеть сайт в действии? На каком порту работает сервер? И, что самое важное, как напрямую достучаться до контейнера из хост-контейнера?

В нашем случае клиент не открывает никакие порты, так что нужно будет перезапустить команду docker run чтобы сделать порты публичными. Заодно давайте сделаем так, чтобы терминал не был прикреплен к запущенному контейнеру. В таком случае можно будет спокойно закрыть терминал, а контейнер продолжит работу. Это называется detached mode.

Откройте http://localhost:32769 в своем браузере.

Замечание: Если вы используете docker-toolbox, то, возможно, нужно будет использовать docker-machine ip default чтобы получить IP-адрес.

Также можете обозначить свой порт. Клиент будет перенаправлять соединения на него.

Чтобы остановить контейнер запустите docker stop и укажите идентификатор (ID) контейнера.

Согласитесь, все было очень просто. Чтобы задеплоить это на реальный сервер, нужно просто установить Докер и запустить команду выше. Теперь, когда вы увидели, как запускать веб-сервер внутри образа, вам, наверное, интересно — а как создать свой Докер-образ? Мы будем изучать эту тему в следующем разделе.

2.2 Образы

Мы касались образов ранее, но в этом разделе мы заглянем глубже: что такое Докер-образы и как создавать собственные образы. Наконец, мы используем собственный образ чтобы запустить приложение локально, а потом задеплоим его на AWS, чтобы показать друзьям. Круто? Круто! Давайте начнем.

Это список образов, которые я скачал из регистра, а также тех, что я сделал сам (скоро увидим, как это делать). TAG — это конкретный снимок или снэпшот (snapshot) образа, а IMAGE ID — это соответствующий уникальный идентификатор образа.

Важно понимать разницу между базовыми и дочерними образами:

Существуют официальные и пользовательские образы, и любые из них могут быть базовыми и дочерними.

2.3 Наш первый образ

Теперь, когда мы лучше понимаем, что такое образы и какие они бывают, самое время создать собственный образ. Цель этого раздела — создать образ с простым приложением на Flask. Для этого пособия я сделал маленькое приложение, которое выводит случайную гифку с кошкой. Ну, потому что, кто не любит кошек? Склонируйте этот репозиторий к себе на локальную машину.

Вначале давайте проверим, что приложение работает локально. Войдите в директорию flask-app командой cd и установите зависимости.

Если все хорошо, то вы увидите вывод как в примере выше. Зайдите на http://localhost:5000 чтобы увидеть приложение в действии.

Выглядит отлично, правда? Теперь нужно создать образ с приложением. Как говорилось выше, все пользовательские образы основаны на базовом образе. Так как наше приложение написано на Питоне, нам нужен базовый образ Python 3. В частности, нам нужна версия python:3-onbuild базового образа с Питоном.

Другими словами, версия onbuild включает хелперы, которые автоматизируют скучные процессы запуска приложения. Вместо того, чтобы вручную выполнять эти задачи (или писать скрипты), образы делают все за вас. Теперь у нас есть все ингредиенты для создания своего образа: работающее веб-приложение и базовый образ. Как это сделать? Ответ: использовать Dockerfile.

2.4 Dockerfile

Dockerfile — это простой текстовый файл, в котором содержится список команд Докер-клиента. Это простой способ автоматизировать процесс создания образа. Самое классное, что команды в Dockerfile почти идентичны своим аналогам в Linux. Это значит, что в принципе не нужно изучать никакой новый синтаксис чтобы начать работать с докерфайлами.

Главное предназначение CMD — это сообщить контейнеру какие команды нужно выполнить при старте. Теперь наш Dockerfile готов. Вот как он выглядит:

Последний шаг — запустить образ и проверить его работоспособность (замените username на свой):

Зайдите на указанный URL и увидите приложение в работе.

Поздравляю! Вы успешно создали свой первый образ Докера!

2.5 Docker на AWS

Что хорошего в приложении, которое нельзя показать друзьям, правда? Так что в этом разделе мы научимся деплоить наше офигенное приложение в облако. Будем использовать AWS Elastic Beanstalk чтобы решить эту задачу за пару кликов. Мы увидим, как с помощью Beanstalk легко управлять и масштабировать наше приложение.

Docker push

Первое, что нужно сделать перед деплоем на AWS это опубликовать наш образ в регистре, чтобы можно было скачивать его из AWS. Есть несколько Docker-регистров (или можно создать собственный). Для начала, давайте используем Docker Hub. Просто выполните:

Если это ваша первая публикация, то клиент попросит вас залогиниться. Введите те же данные, что используете для входа в Docker Hub.

После этого можете посмотреть на свой образ на Docker Hub. Например, вот страница моего образа.

Замечание: один важный момент, который стоит прояснить перед тем, как продолжить — не обязательно хранить образ в публичном регистре (или в любом другом регистре вообще) чтобы деплоить на AWS. Если вы пишете код для следующего многомиллионного стартапа-единорога, то можно пропустить этот шаг. Мы публикуем свой образ чтобы упростить деплой, пропустив несколько конфигурационных шагов.

Теперь наш образ онлайн, и любой докер-клиент может поиграться с ним с помощью простой команды:

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

Beanstalk

AWS Elastic Beanstalk (EB) это PaaS (Platform as a Service — платформа как сервис) от Amazon Web Services. Если вы использовали Heroku, Google App Engine и т.д., то все будет привычно. Как разработчик, вы сообщаете EB как запускать ваше приложение, а EB занимается всем остальным, в том числе масштабированием, мониторингом и даже апдейтами. В апреле 2014 в EB добавили возможность запускать Докер-контейнеры, и мы будем использовать именно эту возможность для деплоя. У EB очень понятный интерфейс командной строки, но он требует небольшой конфигурации, поэтому для простоты давайте используем веб-интерфейс для запуска нашего приложения.

Чтобы продолжать, вам потребуется работающий аккаунт на AWS. Если у вас его нет, то создайте его. Для этого потребуется ввести данные кредитной карты. Но не волнуйтесь, эта услуга бесплатна, и все, что будет происходить в рамках этого пособия тоже бесплатно.

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

К этому моменту инстанс уже должен быть готов. Зайдите на страницу EB и увидите зеленый индикатор успешного запуска приложения.

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

Поздравляю! Вы задеплоили свое первое Докер-приложение! Может показаться, что было очень много шагов, но с командной утилитой EB можно имитировать функциональность Хероку несколькими нажатиями клавиш. Надеюсь, вы согласитесь, что Докер сильно упрощает процесс и минимизирует болезненные моменты деплоя в облако. Я советую вам почитать документацию AWS про single-container Docker environment чтобы понимать, какие существуют возможности в EB.

В следующей, последней части пособия, мы пойдем немного дальше и задеплоим приложение, приближенное к реальному миру. В нем будет постоянное бэкэнд-хранилище. Поехали!

3.0 Многоконтейнерные окружения

В прошлом разделе мы увидели, как легко и просто запускать приложения с помощью Докера. Мы начали с простого статического сайта, а потом запустили Flask-приложение. Оба варианта можно было запускать локально или в облаке, несколькими командами. Общая черта этих приложений: каждое из них работало в одном контейнере.

Если у вас есть опыт управления сервисами в продакшене, то вы знаете, что современные приложения обычно не такие простые. Почти всегда есть база данных (или другой тип постоянного хранилища). Системы вроде Redis и Memcached стали практически обязательной частью архитектуры веб-приложений. Поэтому, в этом разделе мы научимся «докеризировать» приложения, которым требуется несколько запущенных сервисов.

В частности, мы увидим, как запускать и управлять многоконтейнерными Докер-окружениями. Почему нужно несколько контейнеров, спросите вы? Ну, одна из главных идей Докера в том, что он предоставляет изоляцию. Идея совмещения процесса и его зависимостей в одной песочнице (называемой контейнером) и делает Докер мощным инструментом.

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

3.1 SF Food Trucks

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

Бэкэнд приложения написано на Питоне (Flask), а для поиска используется Elasticsearch. Как и все остальное в этом пособии, код находится на Github. Мы используем это приложение, чтобы научиться запускать и деплоить много-контейнерное окружение.

Теперь, когда вы завелись (надеюсь), давайте подумаем, как будет выглядеть этот процесс. В нашем приложении есть бэкэнд на Flask и сервис Elasticsearch. Очевидно, что можно поделить приложение на два контейнера: один для Flask, другой для Elasticsearch (ES). Если приложение станет популярным, то можно будет добавлять новые контейнеры в нужном месте, смотря где будет узкое место.

Отлично, значит нужно два контейнера. Это не сложно, правда? Мы уже создавали Flask-контейнер в прошлом разделе. А для Elasticsearch… давайте посмотрим, есть ли что-нибудь в хабе:

Замечание: если оказывается, что существующий образ не подходит для вашей задачи, то спокойно создавайте свой образ на основе другого базового образа. В большинстве случаем, для образов на Docker Hub можно найти соответствующий Dockerfile на Github. Почитайте существующий Докерфайлы — это один из лучших способов научиться делать свои образы.

Наш Dockerfile для Flask-приложения выглядит следующим образом:

Тут много всего нового. Вначале указан базовый образ Ubuntu LTS, потом используется пакетный менеджер apt-get для установки зависимостей, в частности — Python и Node. Флаг yqq нужен для игнорирования вывода и автоматического выбора «Yes» во всех местах. Также создается символическая ссылка для бинарного файла node. Это нужно для решения проблем обратной совместимости.

Наконец, можно собрать образ и запустить контейнер (замените prakhar1989 на свой username ниже).

При первом запуске нужно будет больше времени, так как клиент Докера будет скачивать образ ubuntu, запускать все команды и готовить образ. Повторный запуск docker build после последующих изменений будет практически моментальным. Давайте попробуем запустить приложение

Упс! Наше приложение не смогло запуститься, потому что оно не может подключиться к Elasticsearch. Как сообщить одному контейнеру о другом и как заставить их взаимодействовать друг с другом? Ответ — в следующей секции.

3.2 Сети Docker

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

Нужно сообщить Flask-контейнеру, что контейнер ES запущен на хосте 0.0.0.0 (порт по умолчанию 9200 ), и все заработает, да? К сожалению, нет, потому что IP 0.0.0.0 это адрес для доступа к контейнеру с хост-машины, то есть с моего Мака. Другой контейнер не сможет обратиться по этому адресу. Ладно, если не этот адрес, то какой другой адрес нужно использовать для работы с контейнером ES? Рад, что вы спросили.

Это хороший момент, чтобы изучить работу сети в Докере. После установки, Докер автоматически создает три сети:

Сеть bridge — это сеть, в которой контейнеры запущены по умолчанию. Это значит, что когда я запускаю контейнер ES, он работает в этой сети bridge. Чтобы удостовериться, давайте проверим:

Не смотря на то, что мы нашли способ наладить связь между контейнерами, существует несколько проблем с этим подходом:

Во-первых, давайте создадим свою сеть:

Команда network create создает новую сеть bridge. Нам сейчас нужен именно такой тип. Существуют другие типы сетей, и вы можете почитать о них в официальной документации.

Зайдите на http://0.0.0.0:5000, и увидите приложение в работе. Опять же, может показаться, что было много работы, но на самом деле мы ввели всего 4 команды чтобы с нуля дойти до работающего приложения. Я собрал эти команды в bash-скрипт.

Теперь представьте, что хотите поделиться приложением с другом. Или хотите запустить на сервере, где установлен Докер. Можно запустить всю систему с помощью одной команды!

Вот и все! По-моему, это невероятно крутой и мощный способ распространять и запускать приложения!

Docker Links

3.3 Docker Compose

До этого момента мы изучали клиент Докера. Но в экосистеме Докера есть несколько других инструментов с открытым исходным кодом, которые хорошо взаимодействуют с Докером. Некоторые из них это:

В этом разделе мы поговорим об одном из этих инструментов — Docker Compose, и узнаем, как он может упростить работу с несколькими контейнерами.

Первый комментарий на самом деле неплохо объясняет, зачем нужен Fig и что он делает:

На самом деле, смысл Докера в следующем: запускать процессы. Сегодня у Докера есть неплохое API для запуска процессов: расшаренные между контейнерами (иными словами, запущенными образами) разделы или директории (shared volumes), перенаправление портов с хост-машины в контейнер, вывод логов, и так далее. Но больше ничего: Докер сейчас работает только на уровне процессов.
Не смотря на то, что в нем содержатся некоторые возможности оркестрации нескольких контейнеров для создания единого «приложения», в Докере нет ничего, что помогало бы с управлением такими группами контейнеров как одной сущностью. И вот зачем нужен инструмент вроде Fig: чтобы обращаться с группой контейнеров как с единой сущностью. Чтобы думать о «запуске приложений» (иными словами, «запуске оркестрированного кластера контейнеров») вместо «запуска контейнеров».

Оказалось, что многие пользователи Докера согласны с такими мыслями. Постепенно, Fig набрал популярность, Docker Inc. заметили, купили компанию и назвали проект Docker Compose.

Давайте посмотрим, сможем ли мы создать файл docker-compose.yml для нашего приложения SF-Foodtrucks и проверим, способен ли он на то, что обещает.

Замечание: Нужно находиться в директории с файлом docker-compose.yml чтобы запускать большую часть команд Compose.

Отлично! Файл готов, давайте посмотрим на docker-compose в действии. Но вначале нужно удостовериться, что порты свободны. Так что если у вас запущены контейнеры Flask и ES, то пора их остановить:

Перейдите по IP чтобы увидеть приложение. Круто, да? Всего лишь пара строк конфигурации и несколько Докер-контейнеров работают в унисон. Давайте остановим сервисы и перезапустим в detached mode:

Не удивительно, но оба контейнера успешно запущены. Откуда берутся имена? Их Compose придумал сам. Но что насчет сети? Его Compose тоже делаем сам? Хороший вопрос, давайте выясним.

Для начала, остановим запущенные сервисы. Их всегда можно вернуть одной командой:

Класс! Теперь в этом чистом состоянии можно проверить, способен ли Compose на волшебство.

Пока все хорошо. Проверим, создались ли какие-нибудь сети:

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

Надеюсь, я продемонстрировал как на самом деле просто управлять многоконтейнерной средой с Compose. В последнем разделе мы задеплоим все на AWS!

3.4 AWS Elastic Container Service

Если вы дочитали до этого места, то скорее всего убедились, что Docker — довольно крутая технология. И вы не одиноки. Облачные провайдеры заметили взрывной рост популярности Докера и стали добавлять поддержку в свои сервисы. Сегодня, Докер-приложения можно деплоить на AWS, Azure,Rackspace, DigitalOcean и много других. Мы уже умеем деплоить приложение с одним контейнером на Elastic Beanstalk, а в этом разделе мы изучим AWS Elastic Container Service (или ECS).

AWS ECS — это масштабируемый и гибкий сервис по управлению контейнерами, и он поддерживает Докер. С его помощью можно управлять кластером на EC2 через простой API. В Beanstalk были нормальные настройки по умолчанию, но ECS позволяет настроить каждый аспект окружения по вашим потребностям. По этой причине ECS — не самый простой инструмент в начале пути.

Вначале нужно установить CLI. На момент написания этого пособия CLI-утилита не доступна на Windows. Инструкции по установке CLI на Mac и Linux хорошо описаны на сайте с официальной документацией. Установите утилиту, а потом проверьте ее работоспособность так:

Теперь настройте CLI:

Команда configure с именем региона, в котором хотим разместить наш кластер, и название кластера. Нужно указать тот же регион, что использовался прри создании ключей. Если у вас не настроен AWS CLI, то следуйте руководству, которое подробно описывает все шаги.

Следующий шаг позволяет утилите создавать шаблон CloudFormation.

Единственные отличия от оригинального файла docker-compose.yml это параметры mem_limit и cpu_shares для каждого контейнера.

Красота! Давайте запустим финальную команду, которая произведет деплой на ECS!

Круто! Теперь приложение запущено. Как к нему обратиться?

Откройте http://54.86.14.14 в браузере, и увидите Food Trucks во всей своей желто-черной красе! Заодно, давайте взглянем на консоль AWS ECS.

Видно, что был создан ECS-кластер ‘foodtrucks’, и в нем выполняется одна задача с двумя инстансами. Советую поковыряться в этой консоли и изучить разные ее части и опции.

Вот и все. Всего несколько команд — и приложение работает на AWS!

4.0 Заключение

Мы подошли к концу. После длинного, изматывающего, но интересного пособия вы готовы захватить мир контейнеров! Если вы следовали пособию до самого конца, то можете заслуженно гордиться собой. Вы научились устанавливать Докер, запускать свои контейнеры, запускать статические и динамические веб-сайты и, самое главное, получили опыт деплоя приложений в облако.

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

4.1 Следующие шаги

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

Ниже — список дополнительных полезных ресурсов. Советую использовать Докер в вашем следующем проекте. И не забывайте — практика приводит к совершенству.

Дополнительные ресурсы

Удачи, юный падаван!

4.2 Фидбек автору

Теперь моя очередь задавать вопросы. Вам понравилось пособие? Оно показалось вам запутанным, или вам удалось научиться чему-то?

Напишите мне (автору оригинального пособия, — прим. пер.) напрямую на prakhar@prakhar.me или просто создайте issue. Я есть в Твиттере, так что если хотите, то можете писать туда.

(Автор оригинального пособия говорит по-английски, — прим. пер.).

Буду рад услышать ваши отзывы. Не стесняйтесь предлагать улучшения или указывать на мои ошибки. Я хочу, чтобы это пособие стало одним из лучших стартовых руководств в интернете. У меня не получится это без вашей помощи.

Источник

jonashackt/docker-hello-world

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Example hello world container showing how to use GitHub Container Registry

As Docker Inc introduced a rate-limiting https://www.docker.com/increase-rate-limits I began to bump into problems like this while running a simple docker run hello-world on GitHub Actions:

Well I thought why not crafting a simple and small hello-world image and publish it to GitHub Container Registry?!

TLDR; Simply run it with:

A simple Go executable

The original hello-world image from Docker also uses a small executable to print a text. I decided to go with golang to create a ultra-small executable myself.

Build it (you need to have go installed with like brew install go ) with:

A Docker multistage Build for GO

As we only need to have Go runtime stuff present to build the binary, we should implement a Docker multi-stage build. Since the GO Docker image https://hub.docker.com/_/golang is quite huge:

Therefore let’s split our Dockerfile a bit:

The second «run» image is based on the same https://hub.docker.com/_/alpine image as the builder image containing the GO runtimes.

Now let’s build and run our image:

The resulting image is around 7.55MB which should be small enough for our use cases.

Publish the Docker image to GitHub Container Registry

Activate improved container support

First we need to activate the Container Registry beta feature in our account: https://docs.github.com/en/packages/guides/enabling-improved-container-support

Authenticate and login to GitHub Container Registry using GITHUB_TOKEN

From March 2021 on we should be able to use our GITHUB_TOKEN to authenticate against the GitHub Container Registry instead of using a separate PAT (see https://github.blog/changelog/2021-03-24-packages-container-registry-now-supports-github_token/)!

So our GHA workflow file publish.yml should look like this:

or Alternatively we can also use the docker/login-action to to the login:

Publish (Push) Container image to GHCR

To link our image to our GitHub repository (this isn’t done automatically since images are treated as GH account global packages), we add a LABEL into our Dockerfile:

With this label the image package gets automatically linked to our repository:

And also the image becomes visible on our repositories main page:

Make your image publicly accessible

To make it publicly accessible we need to move to our user account or orga page. For my account this is https://github.com/jonashackt?tab=packages

We should finally be able to pull and run our image! Just run:

About

Example hello world container showing how to use GitHub Container Registry

Источник

Docker – Hello World

Have you ever experience that in just one second your entire operating system is ready to use?

Yes, you heard it right Docker gives you the facilities to use a new operating system in one second. Docker is a program that uses your base OS resources and only consumes 20MB – 50MB RAM to launch a new OS. In this article, we’ll show you how to install the docker inside Redhat Linux, how to start docker services, how to pull images from the docker hub, and finally how to launch a new container.

In this article, we will discuss the “Hello World” for Docker.

These are the steps to achieve the goal.

Let’s start with the key terminologies that you must know.

Basic terminologies

1. Docker container

Docker container is a separate virtualized environment that is used to test, run and deploy the applications. basically, the docker container is used in application development. If any problem or bug comes then it does not affect our Base OS and it also gives extra security. we can easily create new containers with help of docker images. we can also destroy these containers easily.

2. Docker image

Docker images are like snapshots in VMs. Docker images are executable files that are used to create separate containers in Docker. We create lots of containers using single docker images. Docker hub is a centralized location that is maintaining docker images. You can find Docker images of Hello-world, Ubuntu, Centos, etc. We also create our own customize image using the docker commit command and using Dockerfile and publish or push them on the docker hub.

3. Dockerfile

Dockerfile is a scripted text file that is used to customize our container and install desire software inside the docker container. we just write the commands in Dockerfile and using this file we build our own image. Later we use this image in our container as well as we push the image on Dockerhub.

Docker installation in centos/Redhat

As we discuss earlier Dockerhub has the Hello-world official image so let’s see how to install docker and create containers. First of all, we configure a repo that has docker-ce software using the following command:

After the repository add you can check the repo in (/etc/yum.repos.d/) location. Now you can easily download the docker using the yum command:

Just in your case if the above command gives some error then try the below command

Start and enable the docker services:

Use the below commands to enable and start docker respectively:

Pull the hello-world image

Now pull the hello-world image from docker use the below command:

Execute Hello world:

Use the below command to run the hello-world file in docker:

After running the above command you see some message that prints hello-world which means your docker is successfully installed in your Centos or Redhat Linux.

Источник

Docker hello world example

I assume you have Docker installed in your system by now.

Run Docker hello-world image

Run the docker hello-world image by following the steps below.

Build a custom image from Dockerfile

Download the code example

Steps to build a custom image from a Dockerfile

Watch the screencast below

A closer look at Dockerfile

As explained above, Dockerfile has the instructions or commands that explains to the docker how to and what to build. We will look into this little more in details as this is the most important of Docker tutorial.

FROM: Explains the base image that is used to build the custom hello-docker image. This is like inheritance/reusability.

LABEL: This is to set some labels/meta information about your image. Like version, author, email, license, and etc.

CMD: Command to run in the hello-docker image

There are several other commands as below.

FROM, LABEL, COPY, RUN, EXPOSE, ENV, ADD, COPY, ENTRYPOINT, VOLUME, USER, WORKDIR, ARG, ONBUILD, STOPSIGNAL, HEALTHCHECK, SHELL. All these commands need to be written in capital letter.

In the next tutorial, we will spend some more time in understanding each of these commands. Let me know your questions in the comment below.

Источник

crccheck/docker-hello-world

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

This is a simple Docker image that just gives http responses on port 8000. It’s small enough to fit on one floppy disk:

I made this initially because there were lots of scenarios where I wanted a Docker container that speaks HTTP, but every guide used images that took seconds to download. Armed with a tiny Docker image, I could test things in a fresh environment in under a second. I like faster feedback loops.

THANK YOU to the surprisingly large number of contributors that have made this better for everyone over the years.

Starting a web server on port 80

You can now interact with this as if it were a dumb web server:

Источник

Hello world docker

Learn to build and deploy your distributed applications easily to the cloud with Docker

Written and developed by Prakhar Srivastav

Introduction

What is Docker?

Wikipedia defines Docker as

an open-source project that automates the deployment of software applications inside containers by providing an additional layer of abstraction and automation of OS-level virtualization on Linux.

Wow! That’s a mouthful. In simpler words, Docker is a tool that allows developers, sys-admins etc. to easily deploy their applications in a sandbox (called containers) to run on the host operating system i.e. Linux. The key benefit of Docker is that it allows users to package an application with all of its dependencies into a standardized unit for software development. Unlike virtual machines, containers do not have high overhead and hence enable more efficient usage of the underlying system and resources.

What are containers?

The industry standard today is to use Virtual Machines (VMs) to run software applications. VMs run applications inside a guest Operating System, which runs on virtual hardware powered by the server’s host OS.

VMs are great at providing full process isolation for applications: there are very few ways a problem in the host operating system can affect the software running in the guest operating system, and vice-versa. But this isolation comes at great cost — the computational overhead spent virtualizing hardware for a guest OS to use is substantial.

Containers take a different approach: by leveraging the low-level mechanics of the host operating system, containers provide most of the isolation of virtual machines at a fraction of the computing power.

Why use containers?

Containers offer a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run. This decoupling allows container-based applications to be deployed easily and consistently, regardless of whether the target environment is a private data center, the public cloud, or even a developer’s personal laptop. This gives developers the ability to create predictable environments that are isolated from the rest of the applications and can be run anywhere.

From an operations standpoint, apart from portability containers also give more granular control over resources giving your infrastructure improved efficiency which can result in better utilization of your compute resources.

Google Trends for Docker

Due to these benefits, containers (& Docker) have seen widespread adoption. Companies like Google, Facebook, Netflix and Salesforce leverage containers to make large engineering teams more productive and to improve utilization of compute resources. In fact, Google credited containers for eliminating the need for an entire data center.

What will this tutorial teach me?

This tutorial aims to be the one-stop shop for getting your hands dirty with Docker. Apart from demystifying the Docker landscape, it’ll give you hands-on experience with building and deploying your own webapps on the Cloud. We’ll be using Amazon Web Services to deploy a static website, and two dynamic webapps on EC2 using Elastic Beanstalk and Elastic Container Service. Even if you have no prior experience with deployments, this tutorial should be all you need to get started.

Getting Started

This document contains a series of several sections, each of which explains a particular aspect of Docker. In each section, we will be typing commands (or writing code). All the code used in the tutorial is available in the Github repo.

Note: This tutorial uses version 18.05.0-ce of Docker. If you find any part of the tutorial incompatible with a future version, please raise an issue. Thanks!

Prerequisites

There are no specific skills needed for this tutorial beyond a basic comfort with the command line and using a text editor. This tutorial uses git clone to clone the repository locally. If you don’t have Git installed on your system, either install it or remember to manually download the zip files from Github. Prior experience in developing web applications will be helpful but is not required. As we proceed further along the tutorial, we’ll make use of a few cloud services. If you’re interested in following along, please create an account on each of these websites:

Setting up your computer

Getting all the tooling setup on your computer can be a daunting task, but thankfully as Docker has become stable, getting Docker up and running on your favorite OS has become very easy.

Until a few releases ago, running Docker on OSX and Windows was quite a hassle. Lately however, Docker has invested significantly into improving the on-boarding experience for its users on these OSes, thus running Docker now is a cakewalk. The getting started guide on Docker has detailed instructions for setting up Docker on Mac, Linux and Windows.

Once you are done installing Docker, test your Docker installation by running the following:

Hello World

Playing with Busybox

Now that we have everything setup, it’s time to get our hands dirty. In this section, we are going to run a Busybox container on our system and get a taste of the docker run command.

To get started, let’s run the following in our terminal:

The pull command fetches the busybox image from the Docker registry and saves it to our system. You can use the docker images command to see a list of all images on your system.

Docker Run

Great! Let’s now run a Docker container based on this image. To do that we are going to use the almighty docker run command.

So what we see above is a list of all containers that we ran. Do notice that the STATUS column shows that these containers exited a few minutes ago.

You’re probably wondering if there is a way to run more than just one command in a container. Let’s try that now:

In later versions of Docker, the docker container prune command can be used to achieve the same effect.

Terminology

In the last section, we used a lot of Docker-specific jargon which might be confusing to some. So before we go further, let me clarify some terminology that is used frequently in the Docker ecosystem.

Webapps with Docker

Static Sites

Let’s start by taking baby-steps. The first thing we’re going to look at is how we can run a dead-simple static website. We’re going to pull a Docker image from Docker Hub, run the container and see how easy it is to run a webserver.

Since the image doesn’t exist locally, the client will first fetch the image from the registry and then run the image. If all goes well, you should see a Nginx is running. message in your terminal. Okay now that the server is running, how to see the website? What port is it running on? And more importantly, how do we access the container directly from our host machine? Hit Ctrl+C to stop the container.

Well, in this case, the client is not exposing any ports so we need to re-run the docker run command to publish ports. While we’re at it, we should also find a way so that our terminal is not attached to the running container. This way, you can happily close your terminal and keep the container running. This is called detached mode.

You can open http://localhost:32769 in your browser.

Note: If you’re using docker-toolbox, then you might need to use docker-machine ip default to get the IP.

You can also specify a custom port to which the client will forward connections to the container.

To stop a detached container, run docker stop by giving the container ID. In this case, we can use the name static-site we used to start the container.

Docker Images

We’ve looked at images before, but in this section we’ll dive deeper into what Docker images are and build our own image! Lastly, we’ll also use that image to run our application locally and finally deploy on AWS to share it with our friends! Excited? Great! Let’s get started.

Docker images are the basis of containers. In the previous example, we pulled the Busybox image from the registry and asked the Docker client to run a container based on that image. To see the list of images that are available locally, use the docker images command.

The above gives a list of images that I’ve pulled from the registry, along with ones that I’ve created myself (we’ll shortly see how). The TAG refers to a particular snapshot of the image and the IMAGE ID is the corresponding unique identifier for that image.

An important distinction to be aware of when it comes to images is the difference between base and child images.

Base images are images that have no parent image, usually images with an OS like ubuntu, busybox or debian.

Child images are images that build on base images and add additional functionality.

Then there are official and user images, which can be both base and child images.

Our First Image

This should be cloned on the machine where you are running the docker commands and not inside a docker container.

The next step now is to create an image with this web app. As mentioned above, all user images are based on a base image. Since our application is written in Python, the base image we’re going to use will be Python 3.

Dockerfile

A Dockerfile is a simple text file that contains a list of commands that the Docker client calls while creating an image. It’s a simple way to automate the image creation process. The best part is that the commands you write in a Dockerfile are almost identical to their equivalent Linux commands. This means you don’t really have to learn new syntax to create your own dockerfiles.

The next step usually is to write the commands of copying the files and installing the dependencies. First, we set a working directory and then copy all the files for our app.

Now, that we have the files, we can install the dependencies.

If you don’t have the python:3.8 image, the client will first pull the image and then create your image. Hence, your output from running the command will look different from mine. If everything went well, your image should be ready! Run docker images and see if your image shows.

The last step in this section is to run the image and see if it actually works (replacing my username with yours).

The command we just ran used port 5000 for the server inside the container and exposed this externally on port 8888. Head over to the URL with port 8888, where your app should be live.

Congratulations! You have successfully created your first docker image.

Docker on AWS

What good is an application that can’t be shared with friends, right? So in this section we are going to see how we can deploy our awesome application to the cloud so that we can share it with our friends! We’re going to use AWS Elastic Beanstalk to get our application up and running in a few clicks. We’ll also see how easy it is to make our application scalable and manageable with Beanstalk!

Docker push

The first thing that we need to do before we deploy our app to AWS is to publish our image on a registry which can be accessed by AWS. There are many different Docker registries you can use (you can even host your own). For now, let’s use Docker Hub to publish the image.

If this is the first time you are pushing an image, the client will ask you to login. Provide the same credentials that you used for logging into Docker Hub.

To publish, just type the below command remembering to replace the name of the image tag above with yours. It is important to have the format of yourusername/image_name so that the client knows where to publish.

Once that is done, you can view your image on Docker Hub. For example, here’s the web page for my image.

Note: One thing that I’d like to clarify before we go ahead is that it is not imperative to host your image on a public registry (or any registry) in order to deploy to AWS. In case you’re writing code for the next million-dollar unicorn startup you can totally skip this step. The reason why we’re pushing our images publicly is that it makes deployment super simple by skipping a few intermediate configuration steps.

Now that your image is online, anyone who has docker installed can play with your app by typing just a single command.

If you’ve pulled your hair out in setting up local dev environments / sharing application configuration in the past, you very well know how awesome this sounds. That’s why Docker is so cool!

Beanstalk

Here are the steps:

While we wait, let’s quickly see what the Dockerrun.aws.json file contains. This file is basically an AWS specific file that tells EB details about our application and docker configuration.

The file should be pretty self-explanatory, but you can always reference the official documentation for more information. We provide the name of the image that EB should use along with a port that the container should open.

Hopefully by now, our instance should be ready. Head over to the EB page and you should see a green tick indicating that your app is alive and kicking.

Go ahead and open the URL in your browser and you should see the application in all its glory. Feel free to email / IM / snapchat this link to your friends and family so that they can enjoy a few cat gifs, too.

Cleanup

Once you done basking in the glory of your app, remember to terminate the environment so that you don’t end up getting charged for extra resources.

Congratulations! You have deployed your first Docker application! That might seem like a lot of steps, but with the command-line tool for EB you can almost mimic the functionality of Heroku in a few keystrokes! Hopefully, you agree that Docker takes away a lot of the pains of building and deploying applications in the cloud. I would encourage you to read the AWS documentation on single-container Docker environments to get an idea of what features exist.

In the next (and final) part of the tutorial, we’ll up the ante a bit and deploy an application that mimics the real-world more closely; an app with a persistent back-end storage tier. Let’s get straight to it!

Multi-container Environments

In the last section, we saw how easy and fun it is to run applications with Docker. We started with a simple static website and then tried a Flask app. Both of which we could run locally and in the cloud with just a few commands. One thing both these apps had in common was that they were running in a single container.

Those of you who have experience running services in production know that usually apps nowadays are not that simple. There’s almost always a database (or any other kind of persistent storage) involved. Systems such as Redis and Memcached have become de rigueur of most web application architectures. Hence, in this section we are going to spend some time learning how to Dockerize applications which rely on different services to run.

In particular, we are going to see how we can run and manage multi-container docker environments. Why multi-container you might ask? Well, one of the key points of Docker is the way it provides isolation. The idea of bundling a process with its dependencies in a sandbox (called containers) is what makes this so powerful.

Just like it’s a good strategy to decouple your application tiers, it is wise to keep containers for each of the services separate. Each tier is likely to have different resource needs and those needs might grow at different rates. By separating the tiers into different containers, we can compose each tier using the most appropriate instance type based on different resource needs. This also plays in very well with the whole microservices movement which is one of the main reasons why Docker (or any other container technology) is at the forefront of modern microservices architectures.

SF Food Trucks

The app that we’re going to Dockerize is called SF Food Trucks. My goal in building this app was to have something that is useful (in that it resembles a real-world application), relies on at least one service, but is not too complex for the purpose of this tutorial. This is what I came up with.

The app’s backend is written in Python (Flask) and for search it uses Elasticsearch. Like everything else in this tutorial, the entire source is available on Github. We’ll use this as our candidate application for learning out how to build, run and deploy a multi-container environment.

First up, let’s clone the repository locally.

The flask-app folder contains the Python application, while the utils folder has some utilities to load the data into Elasticsearch. The directory also contains some YAML files and a Dockerfile, all of which we’ll see in greater detail as we progress through this tutorial. If you are curious, feel free to take a look at the files.

Great, so we need two containers. That shouldn’t be hard right? We’ve already built our own Flask container in the previous section. And for Elasticsearch, let’s see if we can find something on the hub.

Quite unsurprisingly, there exists an officially supported image for Elasticsearch. To get ES running, we can simply use docker run and have a single-node ES container running locally within no time.

Note: Elastic, the company behind Elasticsearch, maintains its own registry for Elastic products. It’s recommended to use the images from that registry if you plan to use Elasticsearch.

Let’s first pull the image

and then run it in development mode by specifying ports and setting an environment variable that configures the Elasticsearch cluster to run as a single-node.

Note: If your container runs into memory issues, you might need to tweak some JVM flags to limit its memory consumption.

Note: Elasticsearch takes a few seconds to start so you might need to wait before you see initialized in the logs.

Now, lets try to see if can send a request to the Elasticsearch container. We use the 9200 port to send a cURL request to the container.

Note: if you find that an existing image doesn’t cater to your needs, feel free to start from another base image and tweak it yourself. For most of the images on Docker Hub, you should be able to find the corresponding Dockerfile on Github. Reading through existing Dockerfiles is one of the best ways to learn how to roll your own.

Finally, we can go ahead, build the image and run the container (replace yourusername with your username below).

In the first run, this will take some time as the Docker client will download the ubuntu image, run all the commands and prepare your image. Re-running docker build after any subsequent changes you make to the application code will almost be instantaneous. Now let’s try running our app.

Oops! Our flask app was unable to run since it was unable to connect to Elasticsearch. How do we tell one container about the other container and get them to talk to each other? The answer lies in the next section.

Docker Network

Before we talk about the features Docker provides especially to deal with such scenarios, let’s see if we can figure out a way to get around the problem. Hopefully, this should give you an appreciation for the specific feature that we are going to study.

Okay, so let’s run docker container ls (which is same as docker ps ) and see what we have.

So we have one ES container running on 0.0.0.0:9200 port which we can directly access. If we can tell our Flask app to connect to this URL, it should be able to connect and talk to ES, right? Let’s dig into our Python code and see how the connection details are defined.

To make this work, we need to tell the Flask container that the ES container is running on 0.0.0.0 host (the port by default is 9200 ) and that should make it work, right? Unfortunately, that is not correct since the IP 0.0.0.0 is the IP to access ES container from the host machine i.e. from my Mac. Another container will not be able to access this on the same IP address. Okay if not that IP, then which IP address should the ES container be accessible by? I’m glad you asked this question.

Now is a good time to start our exploration of networking in Docker. When docker is installed, it creates three networks automatically.

The bridge network is the network in which containers are run by default. So that means that when I ran the ES container, it was running in this bridge network. To validate this, let’s inspect the network.

How do we tell the Flask container that es hostname stands for 172.17.0.2 or some other IP since the IP can change?

Since the bridge network is shared by every container by default, this method is not secure. How do we isolate our network?

The good news that Docker has a great answer to our questions. It allows us to define our own networks while keeping them isolated using the docker network command.

Let’s first go ahead and create our own network.

The network create command creates a new bridge network, which is what we need at the moment. In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network. The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other. There are other kinds of networks that you can create, and you are encouraged to read about them in the official docs.

As you can see, our es container is now running inside the foodtrucks-net bridge network. Now let’s inspect what happens when we launch in our foodtrucks-net network.

Head over to http://0.0.0.0:5000 and see your glorious app live! Although that might have seemed like a lot of work, we actually just typed 4 commands to go from zero to running. I’ve collated the commands in a bash script.

Now imagine you are distributing your app to a friend, or running on a server that has docker installed. You can get a whole app running with just one command!

And that’s it! If you ask me, I find this to be an extremely awesome, and a powerful way of sharing and running your applications!

Docker Compose

In this section, we are going to look at one of these tools, Docker Compose, and see how it can make dealing with multi-container apps easier.

The first comment on the forum actually does a good job of explaining what Fig is all about.

So really at this point, that’s what Docker is about: running processes. Now Docker offers a quite rich API to run the processes: shared volumes (directories) between containers (i.e. running images), forward port from the host to the container, display logs, and so on. But that’s it: Docker as of now, remains at the process level.

While it provides options to orchestrate multiple containers to create a single «app», it doesn’t address the management of such group of containers as a single entity. And that’s where tools such as Fig come in: talking about a group of containers as a single entity. Think «run an app» (i.e. «run an orchestrated cluster of containers») instead of «run a container».

It turns out that a lot of people using docker agree with this sentiment. Slowly and steadily as Fig became popular, Docker Inc. took notice, acquired the company and re-branded Fig as Docker Compose.

So what is Compose used for? Compose is a tool that is used for defining and running multi-container Docker apps in an easy way. It provides a configuration file called docker-compose.yml that can be used to bring up an application and the suite of services it depends on with just one command. Compose works in all environments: production, staging, development, testing, as well as CI workflows, although Compose is ideal for development and testing environments.

Let’s see if we can create a docker-compose.yml file for our SF-Foodtrucks app and evaluate whether Docker Compose lives up to its promise.

Note: You must be inside the directory with the docker-compose.yml file in order to execute most Compose commands.

Great! Now the file is ready, let’s see docker-compose in action. But before we start, we need to make sure the ports and names are free. So if you have the Flask and ES containers running, lets turn them off.

Head over to the IP to see your app live. That was amazing wasn’t it? Just a few lines of configuration and we have two Docker containers running successfully in unison. Let’s stop the services and re-run in detached mode.

Unsurprisingly, we can see both the containers running successfully. Where do the names come from? Those were created automatically by Compose. But does Compose also create the network automatically? Good question! Let’s find out.

While we’re are at it, we’ll also remove the foodtrucks network that we created last time.

Great! Now that we have a clean slate, let’s re-run our services and see if Compose does its magic.

So far, so good. Time to see if any networks were created.

You can see that compose went ahead and created a new network called foodtrucks_default and attached both the new services in that network so that each of these are discoverable to the other. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.

Development Workflow

Before we jump to the next section, there’s one last thing I wanted to cover about docker-compose. As stated earlier, docker-compose is really great for development and testing. So let’s see how we can configure compose to make our lives easier during development.

Throughout this tutorial, we’ve worked with readymade docker images. While we’ve built images from scratch, we haven’t touched any application code yet and mostly restricted ourselves to editing Dockerfiles and YAML configurations. One thing that you must be wondering is how does the workflow look during development? Is one supposed to keep creating Docker images for every change, then publish it and then run it to see if the changes work as expected? I’m sure that sounds super tedious. There has to be a better way. In this section, that’s what we’re going to explore.

Let’s see how we can make a change in the Foodtrucks app we just ran. Make sure you have the app running,

Now let’s see if we can change this app to display a Hello world! message when a request is made to /hello route. Currently, the app responds with a 404.

Now let’s try making a request again

Lets see how we can fix it. First off, we need to tell docker compose to not use the image and instead use the files locally. We’ll also set debug mode to true so that Flask knows to reload the server when app.py changes. Replace the web portion of the docker-compose.yml file like so:

With that change (diff), let’s stop and start the containers.

As a final step, lets make the change in app.py by adding a new route. Now we try to curl

Wohoo! We get a valid response! Try playing around by making more changes in the app.

That concludes our tour of Docker Compose. With Docker Compose, you can also pause your services, run a one-off command on a container and even scale the number of containers. I also recommend you checkout a few other use-cases of Docker compose. Hopefully, I was able to show you how easy it is to manage multi-container environments with Compose. In the final section, we are going to deploy our app to AWS!

AWS Elastic Container Service

If you’ve read this far you are pretty much convinced that Docker is a pretty cool technology. And you are not alone. Seeing the meteoric rise of Docker, almost all Cloud vendors started working on adding support for deploying Docker apps on their platform. As of today, you can deploy containers on Google Cloud Platform, AWS, Azure and many others. We already got a primer on deploying single container apps with Elastic Beanstalk and in this section we are going to look at Elastic Container Service (or ECS) by AWS.

AWS ECS is a scalable and super flexible container management service that supports Docker containers. It allows you to operate a Docker cluster on top of EC2 instances via an easy-to-use API. Where Beanstalk came with reasonable defaults, ECS allows you to completely tune your environment as per your needs. This makes ECS, in my opinion, quite complex to get started with.

Luckily for us, ECS has a friendly CLI tool that understands Docker Compose files and automatically provisions the cluster on ECS! Since we already have a functioning docker-compose.yml it should not take a lot of effort in getting up and running on AWS. So let’s get started!

The first step is to install the CLI. Instructions to install the CLI on both Mac and Linux are explained very clearly in the official docs. Go ahead, install the CLI and when you are done, verify the install by running

Next, we’ll be working on configuring the CLI so that we can talk to ECS. We’ll be following the steps as detailed in the official guide on AWS ECS docs. In case of any confusion, please feel free to refer to that guide.

The next step is to configure the CLI.

We provide the configure command with the region name we want our cluster to reside in and a cluster name. Make sure you provide the same region name that you used when creating the keypair. If you’ve not configured the AWS CLI on your computer before, you can use the official guide, which explains everything in great detail on how to get everything going.

The next step enables the CLI to create a CloudFormation template.

Great! Now let’s run the final command that will deploy our app on ECS!

It’s not a coincidence that the invocation above looks similar to the one we used with Docker Compose. If everything went well, you should see a desiredStatus=RUNNING lastStatus=RUNNING as the last line.

Awesome! Our app is live, but how can we access it?

Go ahead and open http://54.86.14.14 in your browser and you should see the Food Trucks in all its black-yellow glory! Since we’re on the topic, let’s see how our AWS ECS console looks.

We can see above that our ECS cluster called ‘foodtrucks’ was created and is now running 1 task with 2 container instances. Spend some time browsing this console to get a hang of all the options that are here.

Cleanup

So there you have it. With just a few commands we were able to deploy our awesome app on the AWS cloud!

Conclusion

And that’s a wrap! After a long, exhaustive but fun tutorial you are now ready to take the container world by storm! If you followed along till the very end then you should definitely be proud of yourself. You learned how to setup Docker, run your own containers, play with static and dynamic websites and most importantly got hands on experience with deploying your applications to the cloud!

I hope that finishing this tutorial makes you more confident in your abilities to deal with servers. When you have an idea of building your next app, you can be sure that you’ll be able to get it in front of people with minimal effort.

Next Steps

Your journey into the container world has just started! My goal with this tutorial was to whet your appetite and show you the power of Docker. In the sea of new technology, it can be hard to navigate the waters alone and tutorials such as this one can provide a helping hand. This is the Docker tutorial I wish I had when I was starting out. Hopefully, it served its purpose of getting you excited about containers so that you no longer have to watch the action from the sides.

Additional Resources

Off you go, young padawan!

Give Feedback

Now that the tutorial is over, it’s my turn to ask questions. How did you like the tutorial? Did you find the tutorial to be a complete mess or did you have fun and learn something?

Send in your thoughts directly to me or just create an issue. I’m on Twitter, too, so if that’s your deal, feel free to holler there!

I would totally love to hear about your experience with this tutorial. Give suggestions on how to make this better or let me know about my mistakes. I want this tutorial to be one of the best introductory tutorials on the web and I can’t do it without your help.

Источник

Docker Hello World Example

Posted by: Hariharan Narayanan in Docker November 4th, 2016 17 Comments Views

In this example we will explore different ways of running basic “Hello, World” containers in Docker.

1. Introduction

Creating a Docker Hello World container and getting it to work verifies that you have the Docker infrastructure set up properly in your development system. We will go about this in 4 different ways:

Thank you!

We will contact you soon.

Table Of Contents

You should have Docker installed already to follow the examples. Please go to the Docker home page to install the Docker engine before proceeding further, if needed. On Linux, please do ensure that your user name is added into the “docker” group while installing so that you need not invoke sudo to run the Docker client commands. You should also have Java and Gradle installed to try examples 3 and 4. Install your favorite J2SE distribution to get Java and install Gradle from gradle.org.

So let us get started!

2. Run Docker Hello World image provided by Docker

This is the simplest possible way to verify that you have Docker installed correctly. Just run the hello-world Docker image in a terminal.

This command will download the hello-world Docker image from the Dockerhub, if not present already, and run it. As a result, you should see the below output if it went well.

Run Docker Hello-World Image

3. Get a “Hello, world” Printed from Another Basic Docker Image

This too is simple. Docker provides a few baseimages that can be used directly to print a “Hello, World”. This can be done as shown below and it verifies that you have a successful installation of Docker.

This command downloads the Alpine baseimage the first time and creates a Docker container. It then runs the container and executes the echo command. The echo command echoes the “Hello, World” string. As a result, you should see the output as below.

Use the Alpine Docker Image to Print Hello World

4. Write a Simple “Hello, World” Program in Java and Run it Within a Docker Container

Let us take it up a notch now. Let us write a simple hello world program in Java and execute it within a Docker container.

4.1. Create HelloWorld.java

First of all, let us create a simple Java program that prints “Hello, World”. Open up your favorite text editor and enter the following code:

This should create the class file Helloworld.class. Normally, we would use the java command to execute HelloWorld as below

Run HelloWorld.main() in Your Native OS

But we want to run this from within a Docker container. To accomplish that we need to create a Docker image. Let us do that now.

4.2. Create a Dockerfile

To create a new Docker image we need to create a Dockerfile. A Dockerfile defines a docker image. Let us create this now. Create a new file named Dockerfile and enter the following in it and save it.

The complete Dockerfile syntax can be found from Docker docs but here is briefly what we have done. We extend our image from the Alpine baseimage. We next added HelloWorld.class into the image with the same name. Later we installed a JRE environment using OpenJDK. Finally, we gave the command to execute when this image is run – that is to run our HelloWorld in the JVM.

4.3. Create Docker Hello World Image and Run it

Now, build an image from this Dockerfile by executing the below command.

As a result of this you should see the following output

Build Docker Image Called docker-hello-world

Finally, run the Docker image to see the «Hello, World» printed.

As a result of this you should see the below output

Run the Docker Image docker-hello-world

That’s it. This verifies that you can create your own custom Docker images too and run them.

5. Execute a “Hello, World” Program in Java Using Gradle and Docker

Let us take it up another notch now. Real world programs are more complex than the ones shown above. So let us create another hello world Java program and run it in a Docker container using a few best-practices of the Java ecosystem. Furthermore, let us set up a Java project using Gradle, add the Docker plugin for Gradle into it, create a Docker image and run it using Gradle.

5.1. Initialize a New Java Project and Create HelloWorld.java

First of all, Create a new folder called “docker-hello-world-example”, open a terminal and change into this folder. Next, use Gradle to initialize a new Java project.

Folder structure for the Sample Java Project Created by Gradle

Now, create a new file src/main/java/com/javacodegeeks/examples/HelloWorld.java and enter the following in it. Save it once done.

5.2. Create a Dockerfile

Next, create a Docker file in src/main/resources called “src/main/resources/Dockerfile” and enter the following. Save and close the file once done.

Let us quickly go through what we did in the above Dockerfile. We derive our image from the Alpine Linux base image. Next, we installed J2SE from OpenJDK. Next, we copied the jar file generated by the build process as app.jar into the Docker image. Finally, we set the command to be run when the Docker container is run which is to execute the app.jar file.

5.3. Include Gradle-Docker Plugin

Next, make the following changes into the build.gradle file to update the Jar manifest.

We set the mainClassName to com.javacodegeeks.examples.HelloWorld and set the same attribute to be inserted into the manifest file of the jar that will be created.

Next, insert the following changes at the very top of build.gradle file to configure and add the Gradle plugins for Docker.

Here we basically added the Gradle plugins called docker and docker-run provided by Palantir. These plugins enable us to create Docker containers and run them using Gradle. We added the URL to tell where to find the gradle-docker plugin ( https://plugins.gradle.org/m2/ ). We also added the plugins into the classpath as build dependencies.

5.4. Configure the Docker Tasks in Gradle Build File

Next, insert the following changes at the bottom of build.gradle file to configure the details of the Docker image.

Finally, insert the following changes at the bottom of build.gradle file to configure the details of the Docker container.

Here we configured the details of the docker container. We assigned the container name “docker-hello-world-container”. We assigned it the image from where to create the container and gave it a command to execute when running the container.

5.5. Create Docker Container and Run it

Now we are ready to build and run this. Use Gradle to build and run this program

You will notice that the code was built, jar was created, Docker image and containers were created, and the container was run too. However, there is no “Hello, World” actually printed on the screen here.

Run the Gradle Tasks clean, build, docker, and dockerrun

The last line simply says that the Docker container ‘docker-hello-world-container’ is running. To see if it printed “Hello, World” successfully, we need to check the logs created by the Docker container. This can be checked by executing the following command.

Check the Docker Container Logs to Check if Hello world was Printed

6. Summary

Источник

Руководство по Docker. Часть 1: образ, контейнер, сопоставление портов и основные команды

Docker — платформа с открытым исходным кодом для создания, развертывания и управления контейнеризированными приложениями.

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

1. Образы и контейнеры

Самые важные концепции Docker!

Образ — это файл, хранящий всю конфигурацию запуска программы в контейнере Docker. Посмотреть на список образов, созданных в системе, можно при помощи следующей команды:

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

Количество контейнеров не ограничено, все они работают на общей инфраструктуре хоста и общей операционной системе. Посмотреть на список контейнеров можно с помощью команды:

2. Запуск первой программы в Docker

Первым делом нужно вывести на экран фразу “Hello, world!”.

Попытка создания и запуска контейнера. Согласно документации API-клиента Docker, в установленном порядке выполняются следующие действия.

3. Основные команды контейнеров Docker

Прочитайте перечень команд управления поведением контейнеров без изменения образов.

4. Командная строка Docker-контейнера

Рассмотрим набор самых часто задаваемых вопросов о пользовательском вводе команд с клавиатуры напрямую в контейнеры Docker.

Иногда удобно напрямую взаимодействовать с командной строкой контейнера. Для поиска ошибок и отладки, или вы можете запустить там все команды Linux одновременно. Убедитесь, что нужный контейнер запущен, а потом введите следующую команду:

sh выдаст разрешение на ввод подсказок ( prompt), и вы сможете выполнять внутри контейнера различные задачи, например:

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

Теперь все знания о полезных командах из двух пунктов руководства помогут вам подготовиться к следующему шагу.

5. Пользовательские образы Docker

Как добавить файлы в контейнер и какую операционную систему выбрать для образа?

Основной файл, хранящий все инструкции. Каждый dockerfile одинаково структурирован. Чтобы создать dockerfile для пользовательского образа необходимо указать:

После создания dockerfile вы сразу попытаетесь собрать образ. Следовательно, Dockerfile отправляется клиенту Docker.

Теперь, глядя на Dockerfile, у вас наверняка возникли вопросы! Ответим на них сейчас:

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

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

Примечание: если вы обновите dockerfile образа и попытаетесь пересобрать его, то Docker получит кэш из предыдущего образа, чтобы пропустить тот же процесс. Он обновит только вновь добавленный раздел в Dockerfile. Порядок в Dockerfile также важен. Если вы измените порядок команд, то кэш обнулится!

6. Запуск веб-приложения в Docker

В этом разделе создадим и докеризируем простое приложение на Node.js на основе пользовательского образа. Не беспокойтесь, вам не нужны знания о Node.js для выполнения пунктов руководства.

7. Docker и сопоставление портов

Рассмотрим, как разобраться в настройках и правильно установить сопоставление портов!

При отправке запроса на порт 8080 вашей локальной машины, он не перенаправляется автоматически на контейнер, так как у контейнера собственное сетевое отображение.

Сопоставление портов позволит запросу на порт 8080 с локальной машины перенаправить запрос на порт 8080 Docker-контейнера, только для входящих запросов.

Выводы

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

Несмотря на успех, стоит упомянуть три распространенные ошибки, допускаемые в процессе работы с Docker Server и Docker Client.

Далее прилагаются скриншоты правильно запущенного в Docker веб-приложения Node.js, чтобы вы могли с ними свериться.

Самостоятельно ознакомьтесь с файлом dockerfile для построения пользовательского образа и запуска веб-приложения на Node.js.

На сегодня все! В следующей части руководства пойдет речь о последовательном создании нескольких контейнеров и докеризации сложных веб-систем со множеством зависимостей.

Источник

Get started with Docker Compose

Estimated reading time: 12 minutes

On this page you build a simple Python web application running on Docker Compose. The application uses the Flask framework and maintains a hit counter in Redis. While the sample uses Python, the concepts demonstrated here should be understandable even if you’re not familiar with it.

Prerequisites

Make sure you have already installed both Docker Engine and Docker Compose. You don’t need to install Python or Redis, as both are provided by Docker images.

Step 1: Setup

Define the application dependencies.

Create a directory for the project:

Create a file called app.py in your project directory and paste this in:

Note the way the get_hit_count function is written. This basic retry loop lets us attempt our request multiple times if the redis service is not available. This is useful at startup while the application comes online, but also makes our application more resilient if the Redis service needs to be restarted anytime during the app’s lifetime. In a cluster, this also helps handling momentary connection drops between nodes.

Create another file called requirements.txt in your project directory and paste this in:

Step 2: Create a Dockerfile

In this step, you write a Dockerfile that builds a Docker image. The image contains all the dependencies the Python application requires, including Python itself.

In your project directory, create a file named Dockerfile and paste the following:

This tells Docker to:

For more information on how to write Dockerfiles, see the Docker user guide and the Dockerfile reference.

Step 3: Define services in a Compose file

Create a file called docker-compose.yml in your project directory and paste the following:

Web service

Redis service

The redis service uses a public Redis image pulled from the Docker Hub registry.

Step 4: Build and run your app with Compose

Compose pulls a Redis image, builds an image for your code, and starts the services you defined. In this case, the code is statically copied into the image at build time.

Enter http://localhost:8000/ in a browser to see the application running.

If you’re using Docker natively on Linux, Docker Desktop for Mac, or Docker Desktop for Windows, then the web app should now be listening on port 8000 on your Docker daemon host. Point your web browser to http://localhost:8000 to find the Hello World message. If this doesn’t resolve, you can also try http://127.0.0.1:8000.

You should see a message in your browser saying:

The number should increment.

Switch to another terminal window, and type docker image ls to list local images.

Stop the application, either by running docker compose down from within your project directory in the second terminal, or by hitting CTRL+C in the original terminal where you started the app.

Step 5: Edit the Compose file to add a bind mount

Edit docker-compose.yml in your project directory to add a bind mount for the web service:

The new volumes key mounts the project directory (current directory) on the host to /code inside the container, allowing you to modify the code on the fly, without having to rebuild the image. The environment key sets the FLASK_ENV environment variable, which tells flask run to run in development mode and reload the code on change. This mode should only be used in development.

Step 6: Re-build and run the app with Compose

From your project directory, type docker compose up to build the app with the updated Compose file, and run it.

Check the Hello World message in a web browser again, and refresh to see the count increment.

Shared folders, volumes, and bind mounts

If your project is outside of the Users directory ( cd

), then you need to share the drive or location of the Dockerfile and volume you are using. If you get runtime errors indicating an application file is not found, a volume mount is denied, or a service cannot start, try enabling file or drive sharing. Volume mounting requires shared drives for projects that live outside of C:\Users (Windows) or /Users (Mac), and is required for any project on Docker Desktop for Windows that uses Linux containers. For more information, see File sharing on Docker for Mac, and the general examples on how to Manage data in containers.

If you are using Oracle VirtualBox on an older Windows OS, you might encounter an issue with shared folders as described in this VB trouble ticket. Newer Windows systems meet the requirements for Docker Desktop for Windows and do not need VirtualBox.

Step 7: Update the application

Because the application code is now mounted into the container using a volume, you can make changes to its code and see the changes instantly, without having to rebuild the image.

Change the greeting in app.py and save it. For example, change the Hello World! message to Hello from Docker! :

Refresh the app in your browser. The greeting should be updated, and the counter should still be incrementing.

Step 8: Experiment with some other commands

The docker compose run command allows you to run one-off commands for your services. For example, to see what environment variables are available to the web service:

At this point, you have seen the basics of how Compose works.

Источник

brentley/docker-hello-world

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Let’s create a hello world project to dockerize

We’ll start by creating our hello world app. This is the example Express app.

When we try to run this, it fails, because there is a dependency requiring the Express npm to be installed.

Let’s install the express npm.

Now when we run the demo hello world app again, it should work

While it’s running, I’ll open a new terminal and curl to see the output

Okay, now let’s dockerize this application!

If we think like a server administrator, building a VM, we can get pretty far along, but still might need to optimize.

Docker images work in layers. With each instruction, we build a layer on top of all of the other layers, making them read-only.

The first line of our docker file is our starting point. To keep things easy, we can start with something we already might know (like centos).

With only this in our Dockerfile, we can build an image:

Let’s look at what happened.

You can see that we pulled an image of CentOS, and it looks like we downloaded the «latest» version of that image. What does latest mean?

This is where we should talk about tags for a second.

Tags are a way of associating different versions of an image with something human readable. In this case, since we didn’t ask for a specific tag, we downloaded the «latest» tag.

Let’s take a look at what tags might be available: https://hub.docker.com/_/centos

So, rather than using latest, it’s usually better to be specific about the version of the image we want to use as our starting point. Let’s add that to our Dockerfile

Now, we can be pretty confident that we’re using an updated centos, that is the version we prefer, so how do we run our app? We have to start by copying it to the image:

Let’s look at the images we have on our system:

Remember how we talked about tagging, and how it makes images friendlier to look at? Let’s tag our image:

Okay, how do we run our image?

Notice we get an error. It looks like we need to install NodeJS:

Now let’s try to curl our hello world app!

This fails, because even though, inside our container we are listening on port 3000, we haven’t set up THE CONTAINER to listen on port 3000.

Confirm with this command (on osx):

If we connect the host port 3000, to the container port 3000, then we should be able to connect to our running application:

Uh Oh. we kinda messed up.

Check out the build context before and after. we went from sending MBs of data to the Docker daemon, to sending KBs of data.

Now that we have excluded node_modules we should make sure we build the modules inside the container.

Let’s test our change to make sure things still work as expected:

Optimizing the container

Okay, it looks like we have a good container. but is it production worthy? Let’s talk about that. first, let’s look at the size of the container:

How can we make this smaller? More efficient? you see our starting point is 202MB, but we’ve grown this thing to 373MB, and our app code is only 2.3MB, so how did we add so much extra stuff?

Let’s look at our Dockerfile again:

We are really doing 4 things that have a chance to add space. the 3 RUN commands, plus the copy of our app code into the container. Remember when we talked about layers? Each one of those writes a new layer. Ideally, we would do everything we can in fewer layers, take advantage of layer caching, then clean up stuff we don’t need anymore.

What if we did this instead?:

Okay, this makes a huge difference. Let’s talk about why:

So with all of this optimization, we started at 202MB, and ended at 260MB. It’s not bad, but what if we could do better? What if we didn’t need to start with 202MB?

Optimizing the build order to take advantage of caching

There is another optimization we can do to optimize how much work needs to be done if we change something in the app. Watch what happens if I change a line in app.js and then rebuilt the container.

We can optimize it like this:

Now if I run this build I get an extra layer, but this layer lets Docker cache the package.json and the installed dendencies separately from the app code. And if I change a line in the app.js file and rerun the build you’ll see that it is able to skip the NPM install because nothing has changed in package.json

This is a huge boost to speed and productivity when working with Docker containers

Use a container specific distribution

There is another distro that is super popular, called Alpine Linux. It’s deisgned for containers. the starting base image is 3MB. Let’s see what it takes to use that image, instead.

by changing the base image, we simplify the build, and go to a final artifact of 49MB.

Pushing to Amazon ECR

Okay, so now what? I can build an image. I can RUN an image, but how do I run it on other machines?

Well, first we need to put the image someplace the other machines can find it.

This is where Amazon ECR comes in to play. ECR is a special artifact store, designed to hold Docker images. It’s compatible with the docker command line tools, so it’s easy to use, but will scale to meet your needs, without worrying about how many containers you push, or how many clients might pull from it.

Pulling from Amazon ECR to a centos server

Now that we’ve pushed to our artifact store, we can go to a fresh server, pull the image and run it, but first we need to install docker.

If this is all we do, we should get an error when trying to log in to ECR.

This is because we haven’t assigned permission to allow ECR usage yet. Let’s do that now by creating a Read Only IAM role, then assigning it to the EC2 instance.

In reality, the permission we used would likely be merged in to your existing EC2 instance role, but I’m not using one right now, so I’ll create one that can be used on any of my instances.

Once we have the IAM role attached, let’s test ECR access again:

This time, we should be logged in.

Next, let’s try to pull our image:

Just to validate our ECR permissions, let’s attempt to push to the registry. With our Read Only permission, this should fail:

Now let’s see if this server has nodejs installed already:

So there is no nodejs installed and no npm command either.

Running our code on a really stripped down server that doesn’t have nodejs

We can test in another shell, and see our app does indeed work! Also, we can verify it’s not running as root, and is just another process on our OS.

Источник

Docker 101: Fundamentals and Practice

by Guilherme Pejon

If you’re tired of hearing your coworkers praise Docker and its benefits at every chance they get, or you’re tired of nodding your head and walking away every time you find yourself in one of these conversations, you’ve come to the right place.

Also, if you are looking for a new excuse to wander off without getting fired, keep reading and you’ll thank me later.

Docker

Here’s Docker’s definition, according to Wikipedia:

Docker is a computer program that performs operating-system-level virtualization.

Pretty simple, right? Well, not exactly. Alright, here’s my definition of what docker is:

Docker is a platform for creating and running containers from images.

Still lost? No worries, that’s because you probably don’t know what containers or images are.

Images are single files containing all the dependencies and configurations required to run a program, while containers are the instances of those images. Let’s go ahead and see an example of that in practice to make things clearer.

Important note: Before you continue, make sure you install docker using the recommended steps for your operating system.

Part 1. «Hello, World!» from a Python image

Go ahead and run the following command:

Don’t worry, I’ll explain that command in a second, but right now you are probably seeing something like this:

It might take a few moments for this command to run for the first time

That means we are currently inside a docker container created from a python 3 docker image, running the python command. To finish off the example, type print(«Hello, World!») and watch as the magic happens.

A «Hello, World!». Much wow!

Alright, you did it, but before you start patting yourself on the back, let’s take a step back and understand how that worked.

Breaking it down

Let’s start from the beginning. The docker run command is docker’s standard tool to help you start and run your containers.

Lastly, python:3 is the base image we used for this container. Right now, this image comes with python version 3.7.3 installed, among other things. Now, you might be wondering where did this image came from, and what’s inside of it. You can find the answers to both of these questions right here, along with all the other python images we could have used for this example.

Last but not least, python was the command we told Docker to execute inside our python:3 image, which started a python shell and allowed our print(«Hello, World!») call to work.

One more thing

That’s because we already downloaded the python:3 image, so our container starts a lot faster now.

Part 2. Automated «Hello World!» from a Python image

What’s better than writing «Hello, World!» in your terminal once? You got it, writing it twice!

Since we cannot wait to see «Hello, World!» printed in our terminal again, and we don’t want to go through the hustle of opening up python and typing print again, let’s go ahead and automate that process a little bit. Start by creating a hello.py file anywhere you’d like.

Next, go ahead and run the following command from that same folder.

This is the result we are looking for:

Great! YAHW (Yet Another «Hello World!»)

Note: I used ls before the command to show you that I was in the same folder that I created the hello.py file in.

As we did earlier, let’s take a step back and understand how that worked.

Breaking it down

We are pretty much running the same command we ran in the last section, apart from two things.

Note: You can use any other name or folder that you want, not only /src

Part 3. Easiest «Hello, World!» possible from a Python image using Dockerfile

Are you tired of saying hello to our beautiful planet, yet? That’s a shame, cause we are gonna do it again!

The last command we learned was a little bit verbose, and I can already see myself getting tired of typing all of that code every time I wanna say «Hello, World!» Let’s automate things a little bit further now. Create a file named Dockerfile and add the following content to it:

Now run this command in the same folder you created the Dockerfile :

All that’s left to do now is to go crazy using this code:

Note that you don’t even need to be in the same folder anymore

You already know how it is. Let’s take a moment to understand how a Dockerfile works now.

Breaking it down

Note: The CMD command can be overwritten at runtime. For instance, if you want to run bash instead, you would do docker run hello bash after building the container.

After all of that, all we need to do is run the usual docker run instruction, but this time with the hello image name at the end of the line. That will start a container from the image we recently built and finally print the good ol’ «Hello, World!» in our terminal.

Extending our base image

What do we do if we need some dependency to run our code that does not come pre-installed with our base image? To solve that problem, docker has the RUN instruction.

Following our python example, if we needed the numpy library to run our code, we could add the RUN instruction right after our FROM command.

Part 4. «Hello, World!» from a Nginx image using a long-lived detached container

I know you are probably tired of hearing me say it, but I have one more «Hello» to say before I go. Let’s go ahead and use our newly acquired docker power to create a simple long-lived container, instead of these short-lived ones we’ve been using so far.

Create an index.html file in a new folder with the following content.

Now, let’s create a new Dockerfile in the same folder.

Lastly, let’s run our newly created image with the following command:

You might be thinking that nothing happened because you are back to your terminal, but let’s take a closer look with the docker ps command.

I had to crop the output, but you’ll see a few other columns there

Hurray! (this is the last time, I promise)

Everything seems to be working as expected, and we are serving a static page through the nginx running inside our container. Let’s take a moment to understand how we accomplished that.

Breaking it down

I’m going to skip the Dockerfile explanation because we already learned those commands in the last section. The only «new» thing in that configuration is the nginx:alpine image, which you can read more about it here.

The build command is exactly like the one we used in the last section as well, we are only using the Dockerfile configuration to build an image with a certain name.

Note: If you want to stop a detached container like this one, you can use the docker ps command to get the container’s name (not image), and then use the docker stop instruction with the desired container’s name at the end of the line.

Part 5. The end

That’s it! If you are still reading this, you have all the basics to start using Docker today on your personal projects or daily work.

Let me know what you thought about this article in the comments, and I’ll make sure to write a follow-up article covering more advanced topics like docker-compose somewhere in the near future.

If you have any questions, please let me know.

Источник

Docker Hello World App

Running a hello world app example in docker is very easy and you can do so without writing a single line of code. All we need is docker run command. In this tutorial, we will learn how to download a docker image from the docker hub, and then run that docker image to start a docker container.

So we will mainly work with docker pull and docker run command in this tutorial. Don’t worry we will cover these commands in upcoming tutorials.

Docker Hello World App

Docker provides a sample hello-world app that will set up a bare minimum container for you in which a C program hello.c is run which has the following code:

The above code is just to give you an idea of the program that the hello-world app runs. No need to waste time on understanding it as we are here to understand how docker container runs.

Run Docker Hello World App

Open your terminal(if using Mac OS) or command prompt and execute the following command:

Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:f9dfddf63636d84ef479d645ab5885156ae030f611a56f3a7ac7f2fdd86d7e4e
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the «hello-world» image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/

As we have a fresh docker installation, and we haven’t written any code, neither we have downloaded any project, then how will the above command run the hello-world app? Is it available with the default docker installation?

Well, the answer is no, we don’t have the code or in docker terminology docker image for the hello-world app. But when we run the docker run command, docker looks for the docker image, in this case, docker image with name hello-world locally, and if the image is not found, then docker connects with docker hub over the internet and downloads the image and then run it.

We can also manually download any image for running a docker container using the docker pull command. So if you want to manually download the docker image with name hello-world from docker hub, then run the following command:

Using default tag: latest
latest: Pulling from library/hello-world
Digest: sha256:f9dfddf63636d84ef479d645ab5885156ae030f611a56f3a7ac7f2fdd86d7e4e
Status: Image is up to date for hello-world:latest
docker.io/library/hello-world:latest

This will download the docker image and will store it locally on your machine. In the above output, it says the image is already up to date because I ran the docker run hello-world command before this and the hello-world docker image was downloaded.

Don’t worry about what Docker Hub is or what Docker images are, we will be learning about them in upcoming tutorials. Just to give you a brief introduction, Docker Hub is an online platform where developers can upload their docker images for anyone to download and use. Hence, you will require an internet connection to download the hello-world docker image.

Источник

Docker: FROM scratch

How to build a minimalistic hello-world Docker image.

We know that Docker images are built up from a series of stacked layers that are themselves each a delta of the changes from the previous layer. For example, let’s consider the Dockerfile for the Docker image nginx:alpine :

The content of the Dockerfile above is excerpted from the docker-nginx repository (link). This Dockerfile contains instructions to build the nginx:alpine Docker image by adding a new writable layer (a.k.a. “ container layer”) on top of a parent image (e.g., the alpine:3.11 image in line 1). The writable layer is usually where we write new files, modify existing files, and delete files, and this layer is the delta from its underlying layers.

Now the question is, what is the lowest, or bottom-most, layer of the Docker images? Or, in other words, how do we build the base images such as alpine (

To answer these questions, we can check the Git repositories for alpine (repo link) and busybox (repo link), and read their build scripts and Dockerfiles. For example, the following screenshot shows the Dockerfile for the busybox image.

In the Dockerfile above, line 1 instructs Docker to build the image starting from the scratch image. Line 2 adds a pre-built root filesystem ( rootfs ) on top of the scratch image. Note that the ADD busybox.tar.xz / command will extract the tar file to the destination / folder. (This is one of the differences between the ADD and COPY commands in Dockerfile instructions.) Line 3 sets up the default entry point and starts a shell for a container running the busybox image.

Now that we know the bottom-most layer in an image can be created from the scratch image. Then what is the scratch image? A good place to dig into images is Docker Hub, as shown in the following screenshot.

Excellent! Now we have a rough idea about the scratch image. How about we build a hello-world Docker image from scratch? The Dockerfile should look like the following.

Since the scratch image doesn’t contain anything, the hello program needs to be a Linux binary that is statically compiled so that it can be executed in a minimalistic Docker container. To create statically compiled binaries, we can build them from code in Go or C/C++. For example, there are several articles (link1, link2, link3) talking about how to create the smallest “hello world” executable in Linux. In this article, I will use the binary from the article Smallest x86 ELF Hello World. We can run the following commands to download a helloworld.tar.gz file from that article and extract it to a folder.

From the screenshot above, we can confirm that the binary file hello is only 142 bytes and it outputs a string “ Hi World ” to console when it runs.

To build an image, we move the Dockerfile to the helloworld directory, and run the following command.

After the image is successfully built, we can check the image size and run it in a Docker container, like below.

The second command runs the hello program in a Docker container, and the hello program outputs “ Hi World ” in the console.

Awesome! That’s all I have today. In this article, we have reviewed the concept of the scratch image and built a minimalistic hello-world Docker image. Thanks for reading!

Источник

Hello World Express App with Docker

Step-by-step process of Dockerization of a Node.js application, using Express as the application framework

Subscribe to our newsletter and never miss any upcoming articles

In this article, I will guide you through the step-by-step process of Dockerization of a Node.js application, using Express as the application framework.

Prerequisites

[google.com]

Node.js

Node is a back-end JavaScript runtime environment. It executes JavaScript code on a computer, such as your dev desktop or a Web server.

The good news is that, because you have Docker, you don’t actually need to install Node.js. In this walkthrough, we will use the Node container image for Docker. This ensures that we avoid version conflicts between the version of Node installed on my machine and yours. It also prevents conflicts during the evolution of the application in production.

Docker

Docker is a platform to build, run, and share applications as containers. If you’re new to containers, here’s a short introductory video.

Step by Step Guide

Create a new folder and navigate into it.

You can do this from the command line using:

Now from the command line, initialize a new npm project:

In terms of other dependencies, we just need Express, the Node.js framework that will help us to create a project with a few simple commands.

Creating Our Express App

Now we are ready to write our first Hello world code. Open the project with your favorite IDE. To open it with VS Code using the terminal, you can run the command:

I also use some VS code extensions that you might find useful:

Your project should look like this:

We will start by creating a simple hello world app using Express and the following sample code:

To do this, we create an index.js file. We can do this in different way but from a Unix command prompt we can type:

And then we populate the file with the following code:

Now we can run this simple application. Remember that Express starts its own Web server, so we don’t need something like nginx or Apache to run our application.

Now let’s check the browser:

Exciting? Not much, but it works!

To run this example, I need to have Node installed on my machine. Which isn’t a big deal, right? If we were in a production environment, we could just Install Node.js, yes?

To start, let’s create a file called Dockerfile (capital d, no extension). A Dockerfile is a text file composed of KEY VALUE pairs. Its keywords are typically written in uppercase.

Let’s examine each line one by one.

The last COPY command is used to copy all folders and files in the current development folder inside the Docker image’s filesystem. But that’s a problem.We have the current node_modules in our development environment, but we don’t want to copy it; we want to install these files from our package.json and package-lock.json files instead. We need this because of two reasons: the first is that our codebase will be way lightweight, and the second one it’s because maybe we want to install just some of the dependencies, for example in production.

To avoid copying some files or folder, we have two approaches:

COPY only the exact files and folders we need. The downside here is that if we add some folder or files outside the existing ones, we need to remember to also add them to the Dockerfile.

CMD: provides a default command for a container, which can be overwritten. In this case, it will replace we typing «node index.js» from the command line

We are going with this second approach here, so let’s create the file. From your desktop command prompt, type:

Don’t forget the dot at the beginning, all lowercase.

Building Our Image

Now it’s time to build our image based on our current Dockerfile. Please note that, at the end of a command, where you see the dot, that’s a path indicating the current directory. It’s common to use this “here” syntax to run a Dockerfile from its current directory. But it can also be run from a different folder.

Some notes on this command:

Let’s spend a minute talking about the build process.

As you can see, there are six stages, which more or less correspond to our Dockerfile lines! Each stage produces a layer for the image. this layered system is very useful, because it allows to save space on the disk (the same layers of the different images is not downloaded multiple times on the same host), and it’s also useful on the subsequent building processes as if a layer hasn’t changed, it’s just cached and it doesn’t have to be built again). In fact, Docker images have a layered system, which you can verify with the «docker history» command:

Now, let’s check our current images:

To run the container based on the image, run this command:

Unfortunately, you’ll see that our command prompt is blocked by our application. To stop it, we can use CTRL+C (or CMD+C on Mac).

Now, if we try to check the current containers:

Or shortly “docker ps” We can’t see the container.

To remove the container, use the docker rm command

Peeking Inside Our Container

Now, let’s try something interesting, let’s see how do we get inside the container. We could use something like SSH for this. But that’s not necessary. Instead, we can use the handy docker exec command:

Here, we launch the bash shell in the current container. We are basically replacing the node index.js command with a running Bash shell.

And lo and behold, we are now inside the container!

we can check the current filesystem. nd if we type:

Pushing Our Image to a Repository

A repository is a set of Images, with different names and tags. It’s useful to have, in the same place, multiple images with different versions of the same version, e.g. the Official Node one.

To push our image to an existing repository, we first need to retag our image with our dockerHub username:

After creating the repository, we can push our image:

Now we can run this image from any machine using the command

Источник

Лабораторная работа: введение в Docker с нуля. Ваш первый микросервис

Привет, хабрапользователь! Сегодня я попробую представить тебе очередную статью о докере. Зачем я это делаю, если таких статей уже множество? Ответов здесь несколько. Во-первых не все они описывают то, что мне самому бы очень пригодилось в самом начале моего пути изучения докера. Во-вторых хотелось бы дать людям к теории немного практики прямо по этой теории. Одна из немаловажных причин — уложить весь накопленный за этот недолгий период изучения докера опыт (я работаю с ним чуть более полугода) в какой-то сформированный формат, до конца разложив для себя все по-полочкам. Ну и в конце-концов излить душу, описывая некоторые грабли на которые я уже наступил (дать советы о них) и вилы, решение которых в докере просто не предусмотрено из коробки и о проблемах которых стоило бы задуматься на этапе когда вас распирает от острого желания перевести весь мир вокруг себя в контейнеры до осознавания что не для всех вещей эта технология годна.

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

Часть 0.0: прогреваем покрышки

Что такое Докер? это такой новомодный способ изоляции ваших приложений друг от друга с помощью linux namespaces. Он крайне легок в управлении, расширении, миграции и подходит для огромного спектра задач начиная от разработки приложений и сборки пакетов и заканчивая тестами-пятиминутками (запустить-проверить 1-2 команды-закрыть и забыть, да так чтобы еще и мусор за тобой прибрали). Читайте подробнее на офф сайте. Стоит только представлять себе на первом этапе, что контейнер состоит из слоев, т.е. из слепков состояний файловой системы. Я расскажу об этом чуть позже.

Лабораторная инфраструктура данной статьи может быть воспроизведена как на одной ОС с Linux на борту, так и на серии виртуальных машин\vps\whatever. Я делал все на одном дедике (dedicated server) с ОС Debian. Здесь и далее я предполагаю что вы работаете в одной ОС Debian 9. Команды и подходы от ОС к ОС могут отличаться, описать все в одной статье нереально, поэтому выбрана наиболее знакомая мне серверная ОС. Надеюсь для вас не составит труда установить себе виртуальную машину и дать ей выход в интернет.

Часть 0.1 Сравнение с VM

Важно помнить, что Docker — средство изоляции процесса(задачи), а это значит относиться к докеру как к виртуалке нельзя. Он является оберткой вокруг средств контейнеризации ( cgroups + namespaces ) конкретно linux kernel. Но он имеет многие похожие фишки, как и у виртуализации:

Часть 0.2 Процессы в контейнерах

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

Часть 0.3 Откуда брать эти ваши контейнеры? как хранить?

Существуют публичные и приватные хранилки официальных и неофициальных образов. Они называются docker registry. Самый популярный из них — Docker hub. Когда вы докеризуете какой-либо сервис, сходите сначала на хаб и посмотрите, а не сделал ли это кто-то уже за вас?

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

Кроме публичных registry существуют еще и приватные — платные и бесплатные. Платные вам понадобятся, когда вы в замучавшись обуслуживанием воскликните «да пусть вот эти ребята следят за всей этой слоёной docker-вакханалией в этих ваших registry». И правда, когда вы активно пользуетесь при DevOps докером, когда люди или автоматика билдит сотни контейнеров, то рано или поздно у вас начнет подгорать от того как это чистить и обслуживать.

Не все конечно так плохо, естественно. Для десятка человек и пары билдов в день подойдет и свой registry. Для личного пользования тем более.

Зачем может пригодиться registry? это единое место хранения и обмена контейнерами между вами, другими людьми или автоматикой. И вот это по-настоящему крутая штука. Положить и забрать готовый контейнер можно всего одной командой, а при условии того что весит он копейки (по сравнению с VM), то плюсы просто на лицо. Правда стоит помнить, что docker — инструмент, docker registry не хранит данных ваших рабочих контейнеров. Таким образом можно иметь крайне удобный воркфлоу: разработчики пишут продукт, билдят новый контейнер, пушат его в репозиторий. Тестироващики забирают его, тестируют, дают отмашку. Девопсы затем с помощью, например, ansible накатывают контейнеры на прод. Причем вам абсолютно не важно, 1 у вас сервер или 100, с помощью ansible и registry раскатывание контейнеров в прод — одно удовольствие. Здесь же и весь фарш с CI — новые версии могут быть автоматически скачаны билд-сервером. Посему очень рекомендую, даже для личного пользования, завести себе VPS\DS с registry, это очень удобно — обмениваться контейнерами.

Скачать образ из репозитория:

Загрузить образ в репозиторий:

В приватные репозитории нужно еще и логиниться, для этого вам пригодится команда

где потребуется ввести логин и пароль.

Запустить свой registry можно всего одной командой:

Подробнее на офф сайте. SSL, авторизация — все это можно.

Часть 0.4 Контейнеры и образы (images)

Докер образ (image) — это некоторый набор слоёв. Каждый слой — результат работы команды в Dockerfile. Грубо говоря образ — это шаблон на основе которого вы будете запускать контейнеры. Все что запускается на основе этого образа есть контейнер, или инстанс. т.е. с одного образа можно запустить несколько одинаковых копий этого образа — контейнеров. Причем потом, после каких-то манипуляций, из этого контейнера можно создать шаблон — новый образ. Хранится все это безобразие в /var/lib/docker.
документация.

Список образов в вашей системе можно глянуть командой:

Часть 0.5 Как именовать контейнеры и образы (images)?

У образа существует 3 поля, имеющих отношения к именованию:

1) Репозиторий
2) Тег
3) Image ID

Репозиторий — реальный или нереальный, это то место, откуда или куда ваш образ будет скачан\загружен, или это просто выдуманное имя, если загружать никуда вы его не собираетесь.
Тег — обычно это версия продукта. По идее — это любой набор символов. (из разрешенного списка [a-z0-9.-] итп.) если тега нет, то автоматически используется слово latest. тег ставится через символ: от имени репозитория и подставляется автоматически если его не указать при push\pull.
ImageID — локально генерируемый уникальный ID вашего образа, по которому этим образом можно оперировать.

Таким образом вы или автор контейнера влияете на репозиторий и\или тег, а система локально — на ID. Но, кстати вам никто не мешает переиспользовать любое чужое имя репозитория, другой вопрос что запушить (push, загрузить) в него вы не сможете

1/2/3-blah.blah.blah — имя вашего локального образа, вы его выдумали
projects/my_first_docker — тоже имя вашего локального образа
projects/my_first_docker:latest — то же самое имя, но с тегом. эквивалентно предыдущему.
projects/my_first_docker:1.13.33 — а вот это уже конкретная версия образа в этом репозитории.
projects/my_first_docker:1.13.34
projects/my_first_docker:1.13.35
… итд — все это один и тот же проект, но версии ваших образов будут разными.

wallarm/node — а вот это уже скачанный с публичного докер хаба образ с лучшим WAF от компании Wallarm.
debian:stretch — образ debian, версия образа — stretch (не число, но слово)
centos:7 — аналогично debian.
mongo:3.2 — образ mongodb версии 3.2, скачанный с публичного репозитория
nginx — latest stable nginx — аналогично.

Причем чаще всего на хабе можно увидеть разнообразные версии нужного вам софта. Так например mongo даст вам скачать и 3.2 и 3.4 и 3.6 и даже дев версию. и разные промежуточные. и еще кучу других.

Следует помнить: один и тот же образ может иметь сколько угодно имен репозитория и тегов, но будет иметь одинаковый imageid. При этом, образ не будет удален, пока все теги этого образа не будут удалены. т.е. скачав образ debian, задав ему новый тег вы получите в списке 2 образа с разными именами, но одинаковыми imageid. и удалив debian:stretch, вы просто удалите один из тегов, а сам образ останется жить.

Чтобы задать другое имя для существующего образа используется команда:

Для удаления образа:

А вот контейнеры имеют 2 имени:

1) CONTAINER ID
2) Name

С id — тут то же самое — это уникальное имя конкретного уникального запущенного инстанса образа. проще говоря — уникальное имя запущенного образа. Образ может быть запущен сколько угодно раз и каждая копия получит уникальное имя.

Для удаления контейнера:

Часть 0.6 Ладно, все это чужие контейнеры, а как мне сделать свое, с нуля?

Для создания своих контейнеров существует механизм сборки — docker build. Он использует набор инструкций в Dockerfile для сборки вашего собственного образа. При сборке контейнера внутри используется оболочка sh и ваши команды исполняются в ней.

Следует знать следующее:

Часть 0.7 Напоследок и «Это не докер-вэй»

Докер довольно таки мусорит слоями при билде. Кроме того вы можете оставлять кучу остановленных контейнеров. Удалить все это одной командой

Это не докер-вэй

Докер по задумке виртуализирует именно один процесс (с любым кол-вом потомков). Никто вам не мешает конечно запихнуть в один контейнер и 10 процессов, но тогда пеняйте на себя.
Сделать это можно с помощью, например, supervisor.

Но, скажете вы, как же быть со службами, которые ну всю свою жизнь будут вместе и не должны разделяться? использовать контент, который будут генерировать друг для дргуга?

Для того чтобы сделать это красиво и правильно есть docker-compose — это yaml файл, который описывает N ваших контейнеров и их взаимоотношения. какой контейнер с каким скрестить, какие порты друг для друга открыть, какими данными поделиться.

В случае с compose вам, на самом деле, и управлять своим проектом проще. например, связка nginx+uwsgi+mongo — это 3 контейнера, хотя точно известно, что никто кроме nginx не будет ходить в uwsgi, а кроме uwsgi — никто в mongo. да и жить они будут всегда вместе. (ЭТО ЧАСТНЫЙ СЛУЧАЙ). Вот тут у нас получается следующая ситуация — ваше приложение (api) будет обновляться часто — вы его пишете и пушите каждый день. а, например, релизы nginx или mongodb выходят куда реже — может месяц, может дольше. Так зачем каждый раз билдить этого тяжеловеса, когда изменения то всего происходят в одном месте? Когда придет время обновить nginx, вы просто смените имя тега и всесто ребилда проекта, просто скачается новый контейнер с nginx.

Часть 1: когда уже практика?

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

1. Попробуем скачать дебиан образ

2. Глянем, что получилось. В моем случае, я для фильтра использовал слово debian, т.к. иначе вывалилось бы в выводе куча других образов. вам его использовать не обязательно. Ну и как результат — у вас будет 2 одинаковых imageid с разными тегами (первые две у меня).
З.Ы. привет в будущее! для тех, кто доживет до debian10 и будет читать эту статью, у вас будет не такой же результат что и у меня. Надеюсь, понимаете почему.

3. Запустим bash-процесс внутри образа debian:stretch. Посмотрите его pid — он равен единице. Т.е. это тот самый главный процесс, вокруг которого мы и пляшем. Обратите внимание — мы не смогли так просто выполнить ps aux — в контейнере нет нужного пакета. поставить его мы можем как и обычно — с помощью apt.

4. Выйдем из контейнера (exit | Ctrl+D ) и попробуем запустить баш заново — это в верхней консоли (вы можете открыть другую, я для простоты скриншотов сделал так). В нижнем окне — посмотрим список запущенных контейнеров

Вот это да! а куда делся procps? да никуда. его тут нет и не было. когда мы запустили образ заново — то взяли тот самый слепок без установленной программы. а куда делся результат нашей работы? А вон он валяется — в состоянии exited. Как и куча других запущенных мною ранее контейнеров и остановленных впоследствии.

Все это — мусор. Но его еще можно оживить:

1. выходим из контейнера в 1-м терминале
2. во втором терминале копируем ID контейнера, подходящего по timeshtamp как и тот который мы тогда остановили
3. в 1 терминале запускаем этот контейнер командой start. он уходит в background
4. во втором терминале смотрим список запущенных контейнеров — по таймштампу тот что запущен 7 секунд — явно наш.
5. Финт ушами. аттачимся к уже запущенному контейнеру с помощью команды exec и запускаем второй инстанс bash’a.
6. выполняем ps aux — обратите внимание, тот, первый bash, с pid 1 живет. а мы в контейнере теперь управляем им через bash с pid=7. и теперь, если мы выйдем, контейнер будет жить.

Итак:
run — взять образ X и создать контейнер Z с процессом Y
exec — взять контейнер Z и запустить в нем процесс N, при этом процесс Y будет работать как и прежде.

1) Контейнер может жить как в background, так и в foreground, лишь бы был жив процесс, который мы виртуализируем.
2) контейнер — это развернутый из образа инстанс
3) контейнеры можно останавливать и запускать без потери данных (но не стоит, это не докер-вэй)

Часть 2: делаем собственный докер-образ

Учимся использовать dockerfile.
Здесь — два подхода к разработке:

1) взять готовый и подточить под себя
2) сделать самому с нуля

Вариант первый — когда вы уверены что за вас прекрасно сделали уже всю работу. Например, зачем устанавливать nginx, когда можно взять готовый официальный контейнер с nginx. Особенно это касается тех систем, которые не ставятся в одну команду или которые например в debian имеют устаревшие версии, а на докер хабе их билдят более свежие стабильные. Тем более там уже сделана автосборка — свежие версии там прилетают довольно быстро.

Вариант второй — вы параноик или вам не нравится подход автора образа (например, официального не нашлось, а есть только на хабе васи пупкина). Никто не мешает посмотреть как сделал это василий, а потом пойти и сделать самому. Ну или в случае если вы просто пишете свою логику, которой точно нигде нет, как например докер образ для билда ваших deb-пакетов в jenkins. А ведь это очень удобно!

Dockerfile это файл с набором инструкций, которые будут совершены в чистом контейнере указанного вами образа, а на выходе вы получите свой образ.

Самое главное что вам нужно указать — это директивы FROM и CMD (в принципе не обязательно). Приведу пример такого файла:

FROM — какой образ взять за основу.
MAINTAINER — автор данной разработки (кого пинать за работу этого, нового образа)
RUN — команда, исполняемая внутри контейнера, на основании которой будет получен новый образ. Обратите внимание — обычные bash-переносы и && — делает код читаемым и красивым.
Вы также можете писать хоть 10 RUN — команд (но каждая с новой строки), в которых описывать свою логику.
EXPOSE — какие порты, по какому протоколу будут доступны снаружи контейнера при использовании docker-compose. Тут важно помнимать, что это не значит что они будут доступны извне сразу. т.е. имеется ввиду, что пока вы при запуске этого образа не укажете мапинг портов хост: контейнер, никак внутрь попасть не получится. поэтому нужно знать какие порты у вас на каком этапе прописаны:

И только так — получается, обращаясь на хост по 80 порту вы мапитесь в контейнер на 80 порт. при запуске контейнера этот порт был открыт, а внутри контейнера приложение слушает 80 порт. и так, вы с 80 порта хоста попадете на 80 порт приложения. Естественно порты можно делать любыми. Так, можно запустить множество контейнеров, внутри которых nginx’ы слушают 80-й порт, а мапинг снаружи сделать такой: 8000:80, 8001:80, 8002:80… ну итд, идея понятна. таким образом можно сделать 1 образ с одним конфигом, а запустить его паралельно и независимо множество раз.

CMD — и вот это самое ключевое место. Это та команда, которая будет выполняться при запуске контейнера и работать все это время. Помните да? пока работает процесс, живет контейнер. Здесь подход такой же как в systemd — процесс не должен уходить в background — это незачем, процесс то всего один внутри этого контейнера. Отсюда кстати и разные подходы логирования. например можно оставлять вывод в STDOUT, а можно в логи. Главное, чтобы процесс (главный процесс) после запуска оставался жить. а форков-тредов может быть сколько душе угодно.
Кроме CMD есть еще один вид шаманства — ENTRYPOINT. это обычно shell скрипт, которому в качестве аргумента передается значение CMD.

Нужно запомнить следующие вещи:

1) итоговая команда запуска процесса в контейнере = сумма ENTRYPOINT + CMD.
2) вы можете писать в докер файле любой вариант сочетания entrypoint и cmd — оставлять или то или другое, или оба сразу.

Зачем нужна такая сложность? Правильные пацаны пишут entrypoint для раскрытия всего многообразия возможностей. Если вы пишете образ чисто под себя, можно оставить чисто только один CMD и не писать ENTRYPOINT вообще.

Это примитивный пример что можно сделать, манипулируя вводами. Рассмотреть можно десятки сценариев различного использования комбинаций ENTRYPOINT+CMD. Просто помните, что можно предусмотреть несколько различных видов запуска вашего контейнера у конечного пользователя, который не имеет досупа к вашему dockerfile.

Помимо указанных мною команд, существуют и многие другие, например ADD, COPY — позволяет положить набор данных внутрь контейнера, причем если ADD в качестве источника указать архив, она распакует и положит содержимое в указанное место. удобно для редко изменяемого набора файлов.

Порядок в Dockerfile важен! (с точки зрения оптимизации)
При внесении изменений в Dockerfile и последующий ребилд образа затрагивает тот набор команд, начиная с которого происходит изменение.
Пример:

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

Часть 3: связь ФС контейнера с хостом

Теперь давайте рассмотрим способ доступности данных с хостовой ос из контейнера. Причин этого может быть несколько: передача файлов, конфигурации, или просто сохранение обработанных данных на диск. Как я уже упоминал ранее данные не пропадают просто так если выключить контейнер, но они и остаются в этом контейнере. вытащить потом их — это ненужная и глупая задача. Докер-вэй — монтирование хостового каталога\файла внутрь контейнера. А если проще — мапинг папки\файла снаружи на папку\файл внутри. поскольку это монтирование, то изменение с одной стороны всегда будет видно и с другой. Таким образом, внося изменение в конфиг с хостовой ос — вы можете заставить сервис внутри контейнера работать по-другому. И наоборот — для сохранения базы данных на хосте в одном, строго определенном, удобном для вас месте. Или логов.

В этом месте позволю себе дать вам еще один линк на полезный ман, а именно на статью-сборник команд по докеру с кратким пояснением.Тыц

В отдельных случаях проще передавать переменные сред окружения, чем конфиги. и докер позволяет это делать, как зашитыми для билда в Dockerfile (ENV key=value), так и через ключ при запуске контейнера, так и через отдельный файл, если таких переменных много.

Часть 4: Удобный запускатор ваших сервисов

Когда вы уже набилдили себе парочку контейнеров, возникает вопрос, как же их автоматически запускать, не прикладывая к этому усилий? ответ прост — через systemd!

Например, создайте файл:

и занесите туда строки:

на что здесь следует обратить внимание:

Вот и пожалуйста — управляем вашей службой как обычным systemd демоном, а journalctl — смотрим stdout вашего демона.

Часть 5: приблизимся к реальности. Построим нашу инфраструктуру

Т.е. будет 3 контейнера, первый будет ставить задачи в очередь, последний считывать. Все это будет управляться через systemd.

sender.py будет ставить каждые 5 секунд в очередь рандомное число от 1 до 7, а воркер (receiver.py) будет считывать это число и имитировать работу — методом простоя кол-ва секунд равное полученному числу.

Мы будем пытаться сделать наши микросервисы так, как это делают правильные пацаны — внутри контейнера код сервиса, а конфиги и логи — снаружи. Это позволит нам поменять адреса очереди, логин, пароль итд без нового билда контейнера. Просто поправить файлик и перезапустить контейнер, вот и все дела. Таким образом нам понядобится директория в /etc и в /var/log, куда мы будем мапить логи и конфиги, соответственно. Вообще такой подход удобен. зайдя на любой сервер с докером, где могут сосуществовать рядом один или несколько микросервисов, вы всегда знате где искать конфиги или логи. А главное, у вас на сервере будет полная чистота. ssh да docker, чего еще надо? (ну, много чего, понятно, например службу мониторинга или puppet, но мы уже избавляемся от кучи всего сервисо-зависимого. А главное — сервис уже не зависит от хостовой ОС. Имейте весь парк серверов на дебиане, а внутри контейнера — все что угодно. Да, эти же аргументы приводят и к виртуализации, но тут история куда легковеснее. ведь мы тащим по сервакам инструмент, а не целую виртуализированную ОС)

1. RabbitMQ
RabbitMQ — диспетчер обмена сообщениями между приложениями. в нашем случае будет использована примитивная очередь. в эту очередь будет помещаться задание и приниматься воркером. Конфиги настройки очереди мы захардкодим внутрь контейнера. Всего в папке rabbitmq у нас будет 3 файла — Dockerfile и 2 файла с конфигами. Их содержимое — в спойлерах под листингом. Настройка очереди, пользователя, прав доступа — в json файле definitions.

Источник

joshuaconner/hello-world-docker-bottle

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

A simple Python «hello world» server in Docker using bottle.

Running from the index.docker.io image

This image exists in the index.docker.io registry already, so you can run it with:

This will map port 8080, which the server is listening on, to a dynamically allocated port on the host. You can see which port by running docker ps :

This shows that port 8080 on the container is mapped to port 49173 on the host. Thus, assuming curl is installed (if not, run sudo apt-get install curl first), you can do:

Building from source

You can also build from source using:

Linking to another container

If you’d like to link to another container, the image exposes port 8080 as well.

Then, running env in the second container will show the information exposed about our linked container

If we were to install curl in this container with apt-get install curl we could then do:

About

A simple Python «hello world» server in Docker using bottle.

Источник

dstar55/docker-hello-world-spring-boot

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Hello World sample shows how to deploy SpringBoot RESTful web service application with Docker

Clone source code from git

Build Docker image

Maven build will be executes during creation of the docker image.

Note:if you run this command for first time it will take some time in order to download base image from DockerHub

Run Docker Container

the respone should be:

Stop Docker Container:

Run with docker-compose

Build and start the container by running

Test application with curl command

Источник

adam-golab/docker-hello-world

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Simple http ‘hello world’ for load balancer testing

It shows Hello for every request, so it is possible to customize the response. Useful for checking a load balancer configuration.

Running a simple test

Will result in a single instance running on the provided via env PORT.

About

Simple Hello World Docker image that can be customizable via ENV variables

Источник

shubhag/docker-nodejs-helloworld

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

It is a simple hello world application to get to know about docker and nodejs. In the first part, we will create a simple nodejs web application and then we will build a docker image for the web application and lastly we will push the docker image on dockerhub.

Node.js hello world

Make sure to have node.js installed on your system. If not, install it from https://nodejs.org/en/download/package-manager/

Create a server.js file and insert the below given code in it.

Let’s try to understand what we are trying to do with these sets of instructions.

Now let’s initialize package.json to list all the dependencies needed for the server to run.

In the package.json, we have listed express module and its latest version. Name, version, description and author are optional parameters. Now let us install the dependencies using

Finally, start the server using

Open localhost:3000 on your browser. Here you will get a «Hello world» message.

Dockerizing Node.js helloworld application

We have created our node.js hello world application. Now let’s try to dockerize it.

Let’s create a docker file and save it as Dockerfile to build an image of our hello world application.

In this Dockerfile,

Now, let’s build this image using

-t parameter here specifies the name for the image (you can give any name)

Finally to run the docker container using the previously build image, use

Now, open localhost:3000 in your browser. Voila, you have dockerized your node.js hello world application.

Pushing helloworld image to dockerhub

Docker allows you to push your images on dockerhub which then can be later used. The main advantage is if you want to run your dockerized helloworld or any other application and you do not have the docker image of it present on your system, then you can just pull that image from dockerhub and run your application without bothering about building that image again.

In order to push an image on dockerhub, signup for dockerhub. After signup, login to dockerhub using your login credentials.

Now, we have to re-tag our hello-world image in order to include username(dockerhub username) as well in the tag.

Источник

karthequian/docker-helloworld

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

A simple helloworld app for docker

A simple nginx helloworld application that helps you learn docker image pulls. Runs on port :80

To pull this image:

About

A simple helloworld app for docker. One of the most popular helloworld docker containers

Источник

KEINOS/hello-docker-compose

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

docker-compose to hello-world

About

✅ Simplest «Hello-World» docker-compose YAML. As simple as «docker run hello-world».

Resources

License

Stars

Watchers

Forks

Releases

Packages 0

Languages

Footer

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Learn how to work with Docker and JetBrains Rider in our development environment.

Docker Hello, World

What tutorial would be complete without a «Hello, World» application? Starting from JetBrains Rider’s new solution dialog, we can select Console Application from the templates. In the configuration window on the right, we need to pick the Linux option from the Docker Support selection.

Note the use of the AS keyword. We’re giving build steps intermediate image names so we can reference them throughout the containerization process. The next few lines will use our previous build image to publish our project, assuming it succeeded to build.

Great! Now, let’s run this application inside a container. We’ll go through two ways: Docker CLI and using JetBrains Rider’s Docker integration.

The reason lies in how Docker stores images. Each step in the Dockerfile is a separate read-only layer, and the Docker engine will only replace layers when there are changes. Updating code typically happens more than adding or updating package references, and separating the two ensures that a full package restore is only executed when that layer changes. The management of layers allows Docker to reuse and speed up image builds.

Docker CLI

Running the command, we see the following output in our terminal.

Running the command will give us the output from our first running Docker-hosted application.

JetBrains Rider Docker Integration

Congratulations, we did it! Now, let’s look at the easier way to build and run Docker containers using JetBrains Rider.

JetBrains Rider comes bundled with Docker integration, giving developers who prefer a GUI experience all the tools necessary to define, build, and deploy images. With the Dockerfile in our editor, we’ll see two green chevrons in our file’s top-left.

Let’s set some command-line flags we had during our CLI experience. We need to click the chevrons and select the Edit HelloDocker/Dockerfile option.

Once we’ve applied our changes, we can run them either from the dialog or from the editor window using the chevrons. We’ll see our image along with the container in the Services tool window.

We’ll talk more about the Services tool window in the following sections of this tutorial.

There we have it! We’ve created an image from our Dockerfile definition using the Docker CLI and JetBrains Rider’s docker integration. Developers should be familiar with the CLI, but there’s no beating the convenience of clicking a few buttons.

Источник

Hello world в контейнере

Итак, что же это за штуковина Докер?

Запуск Hello world

Давайте запустим контейнер hello world.

вы только что запустили свой первый контейнер!

docker run запускает контейнер.

ubuntu если образ который вы запускаете, к примеру образ ОС Ubuntu. При задании образа, Docker сначала ищет его на хосте Докер. Если образ не существует локально, то образ извлекается из реестра Docker Hub.

/bin/echo команда выполняемая внутри контейнера.

Контейнер запущен. Docker создает новое окружение Ubuntu и выполняет команду /bin/echo выводящую:

Что же происходит с контейнером после этого? Итак, Docker контейнеры выполняются только пока активна команда. Таким образом, в приведенном выше примере, контейнер останавливается после того, как команда будет выполнена.

Интерактивное выполнение контейнера

Давайте опробуем новую команду для запуска контейнера.

Контейнер запущен и мы видим командную строку «внутри» контейнера:

Давайте попробуем выполнить несколько команд внутри контейнера:

Теперь вы можете поиграть с командной строкой контейнера. После чего выполните команду exit или нажмите Ctrl-D чтобы выйти из командной строки контейнера.

Примечание:Как и наш предыдущий контейнер, после завершения процесса Bash shell контейнер останавливается.

Запуск Hello world как демона

Давайте создадим контейнер который будет работать как демон.

Наконец, мы задаем команду для запуска:

Эта длинная строка является ID контейнера. С этим уникальным идентификатором контейнера мы можем работать.

Примечание: ID контейнера длинный и громоздкий. Позже мы рассмотрим короткие ID и способы именовать контейнеры для упрощения работы с ними.

Мы можем использовать ID контейнера что бы посмотреть что же происходит внутри нашего hello world демона.

В этом примере, мы можем видеть наш демонизированный контейнер. Команда docker ps возвращает полезную информацию:

Примечание: Docker автоматически генерирует имя для всех запускаемых контейнеров. Мы рассмотрим как давать свои собственные имена немного позже.

Потрясающе! Демон работает и вы создали свое первое фоновое приложение в Докер!

Теперь используйте команду docker stop что бы остановить наш контейнер.

Команда docker stop говорит Docker остановить контейнер и вернуть его имя.

Отлично. Наш контейнер остановлен.

Следующие шаги

Теперь, вы узнали основы Docker и выполнили парочку дополнительных задач. Посетите раздел Запуск простого приложения что бы научиться строить веб приложения с помощью Docker.

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

Источник

Использование Docker для сборки и запуска проекта на C++

В этой публикации речь пойдет о том, как выполнить сборку C++ проекта, использующего GTest и Boost, при помощи Docker. Статья представляет собой рецепт с некоторыми поясняющими комментариями, представленное в статье решение не претендует на статус Production-ready.

Зачем и кому это может понадобиться?

Предположим, что вам, как и мне очень нравится концепция Python venv, когда все нужные зависимости расположены в отдельной, строго определенной директории; или же вам необходимо обеспечить простую переносимость среды сборки и тестирования для разрабатываемого проекта, что очень удобно, например, при присоединении нового разработчика к команде.

Эта статья будет особенно полезна начинающим разработчикам, кому необходимо выполнить базовую настройку окружения для сборки и запуска C++ проекта.

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

Установка Docker

Все, что вам понадобится, для реализации проекта, представленного в этой статье — это Docker и доступ в интернет.

Docker доступен под платформы Windows, Linux и Mac. Официальная документация.

Так как я использую машину с Windows на борту, мне было достаточно скачать инсталятор и запустить.

Следует учесть, что на данный момент Docker под Windows использует Hyper-V для своей работы.

Проект

В качестве проекта будем подразумевать CommandLine приложение, выводящее строку «Hello World!» в стандартный поток вывода.

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

Структура нашего проекта будет выглядеть следующим образом:

Файл CMakeLists.txt содержит описание проекта.
Исходный код файла:

Файл sample_hello_world.h содержит описание класса HelloWorld, отправляя экземпляр которого в поток, будет выводиться строка «Hello World!». Такая сложность обусловлена необходимостью тестирования кода нашего приложения.
Исходный код файла:

Файл main.cpp содержит точку входа нашего приложения, добавим также Boost.Program_options, чтобы симулировать реальный проект.

Исходный код файла:

Файл test.cpp содержит необходимый минимум — тест функциональности класса HelloWorld. Для тестирования используем GoogleTest.
Исходный код файла:

Далее, переходим к самому интересному — настройке сборочного окружения при помощи Dockerfile!

Dockerfile

Для сборки будем использовать gcc последней версии.
Dockerfile содержит два этапа: сборка и запуск нашего приложения.
Для запуска используем Ubuntu последней версии.

Полагаю, пока переходить к сборке и запуску приложения!

Сборка и запуск

Для сборки нашего приложения и создания Docker-образа достаточно будет выполнить следующую команду:

Для запуска приложения используем команду:

Увидим заветные слова:

Для передачи параметра достаточно будет добавить его в вышеприведенную команду:

Подводим итоги

В результате мы создали полноценное C++ приложение, настроили окружение для его сборки и запуска под Linux и завернули его в Docker-контейнер. Таким образом, освободив последующих разработчиков от необходимости тратить время на настройку локальной сборки.

Источник

docker-archive/dockercloud-hello-world

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Sample docker image to test docker deployments

Build and run using Docker Compose:

Deploying to Docker Cloud

About

Resources

License

Stars

Watchers

Forks

Releases

Packages 0

Contributors 5

Languages

Footer

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

vpsx / docker-hello-world Goto Github PK

License: Apache License 2.0

Dockerfile 45.55% JavaScript 54.45%

docker-hello-world’s Introduction

Let’s create a hello world project to dockerize

We’ll start by creating our hello world app. This is the example Express app.

When we try to run this, it fails, because there is a dependency requiring the Express npm to be installed.

Let’s install the express npm.

Now when we run the demo hello world app again, it should work

While it’s running, I’ll open a new terminal and curl to see the output

Okay, now let’s dockerize this application!

If we think like a server administrator, building a VM, we can get pretty far along, but still might need to optimize.

Docker images work in layers. With each instruction, we build a layer on top of all of the other layers, making them read-only.

The first line of our docker file is our starting point. To keep things easy, we can start with something we already might know (like centos).

With only this in our Dockerfile, we can build an image:

Let’s look at what happened.

You can see that we pulled an image of CentOS, and it looks like we downloaded the «latest» version of that image. What does latest mean?

This is where we should talk about tags for a second.

Tags are a way of associating different versions of an image with something human readable. In this case, since we didn’t ask for a specific tag, we downloaded the «latest» tag.

Let’s take a look at what tags might be available: https://hub.docker.com/_/centos

So, rather than using latest, it’s usually better to be specific about the version of the image we want to use as our starting point. Let’s add that to our Dockerfile

Now, we can be pretty confident that we’re using an updated centos, that is the version we prefer, so how do we run our app? We have to start by copying it to the image:

Let’s look at the images we have on our system:

Remember how we talked about tagging, and how it makes images friendlier to look at? Let’s tag our image:

Okay, how do we run our image?

Notice we get an error. It looks like we need to install NodeJS:

Now let’s try to curl our hello world app!

This fails, because even though, inside our container we are listening on port 3000, we haven’t set up THE CONTAINER to listen on port 3000.

Confirm with this command (on osx):

If we connect the host port 3000, to the container port 3000, then we should be able to connect to our running application:

Uh Oh. we kinda messed up.

Check out the build context before and after. we went from sending MBs of data to the Docker daemon, to sending KBs of data.

Now that we have excluded node_modules we should make sure we build the modules inside the container.

Let’s test our change to make sure things still work as expected:

Optimizing the container

Okay, it looks like we have a good container. but is it production worthy? Let’s talk about that. first, let’s look at the size of the container:

How can we make this smaller? More efficient? you see our starting point is 202MB, but we’ve grown this thing to 373MB, and our app code is only

Let’s look at our Dockerfile again:

We are really doing 4 things that have a chance to add space. the 3 RUN commands, plus the copy of our app code into the container. Remember when we talked about layers? Each one of those writes a new layer. Ideally, we would do everything we can in fewer layers, take advantage of layer caching, then clean up stuff we don’t need anymore.

What if we did this instead?:

Okay, this makes a huge difference. Let’s talk about why:

So with all of this optimization, we started at 202MB, and ended at 260MB. It’s not bad, but what if we could do better? What if we didn’t need to start with 202MB?

Optimizing the build order to take advantage of caching

There is another optimization we can do to optimize how much work needs to be done if we change something in the app. Watch what happens if I change a line in app.js and then rebuilt the container.

We can optimize it like this:

Now if I run this build I get an extra layer, but this layer lets Docker cache the package.json and the installed dendencies separately from the app code. And if I change a line in the app.js file and rerun the build you’ll see that it is able to skip the NPM install because nothing has changed in package.json

This is a huge boost to speed and productivity when working with Docker containers

Use a container specific distribution

There is another distro that is super popular, called Alpine Linux. It’s deisgned for containers. the starting base image is 3MB. Let’s see what it takes to use that image, instead.

by changing the base image, we simplify the build, and go to a final artifact of 49MB.

Pushing to Amazon ECR

Okay, so now what? I can build an image. I can RUN an image, but how do I run it on other machines?

Well, first we need to put the image someplace the other machines can find it.

This is where Amazon ECR comes in to play. ECR is a special artifact store, designed to hold Docker images. It’s compatible with the docker command line tools, so it’s easy to use, but will scale to meet your needs, without worrying about how many containers you push, or how many clients might pull from it.

Pulling from Amazon ECR to a centos server

Now that we’ve pushed to our artifact store, we can go to a fresh server, pull the image and run it, but first we need to install docker.

If this is all we do, we should get an error when trying to log in to ECR.

This is because we haven’t assigned permission to allow ECR usage yet. Let’s do that now by creating a Read Only IAM role, then assigning it to the EC2 instance.

In reality, the permission we used would likely be merged in to your existing EC2 instance role, but I’m not using one right now, so I’ll create one that can be used on any of my instances.

Once we have the IAM role attached, let’s test ECR access again:

This time, we should be logged in.

Next, let’s try to pull our image:

Just to validate our ECR permissions, let’s attempt to push to the registry. With our Read Only permission, this should fail:

Now let’s see if this server has nodejs installed already:

So there is no nodejs installed and no npm command either.

Running our code on a really stripped down server that doesn’t have nodejs

We can test in another shell, and see our app does indeed work! Also, we can verify it’s not running as root, and is just another process on our OS.

Источник

В этом учебнике рассмотрены следующие задачи.

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

Предварительные требования

Установите следующие необходимые компоненты:

Дерево папок будет выглядеть следующим образом:

Шаблон по умолчанию создает приложение, которое выводит текст в терминал и затем завершает работу. В этом руководстве описано, как использовать приложение с бесконечным циклом выполнения. Откройте файл Program.cs в текстовом редакторе.

Если вы используете Visual Studio Code, в предыдущем сеансе терминала введите следующую команду:

Откроется папка App, которая содержит проект в Visual Studio Code.

Файл Program.cs должен выглядеть как следующий фрагмент кода C#:

Замените его кодом, который считает числа каждую секунду:

Получите список файлов для папки publish из папки App, чтобы проверить, был ли создан файл DotNet.Docker.dll.

Создание файла Dockerfile

Файл Dockerfile используется командой docker build для создания образа контейнера. Это текстовый файл с именем Dockerfile, не имеющий расширения.

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

В терминале выполните следующую команду:

counter-image Репозиторий — это имя образа. latest Тег — это тег, используемый для обозначения изображения. 2f15637dc1f6 — Это идентификатор образа. 10 minutes ago — Время создания образа. 208MB — Это размер изображения. Последними этапами Dockerfile является создание контейнера из образа и запуск приложения, копирование опубликованного приложения в контейнер и определение точки входа.

Команда COPY предписывает Docker скопировать указанную папку на вашем компьютере в папку в контейнере. В этом примере папка publish копируется в папку с именем app в контейнере.

WORKDIR Команда изменяет текущий каталог внутри контейнера на приложение.

Для повышения безопасности можно отказаться от конвейера диагностики. Если вы отказываетесь от этого, он позволяет контейнеру выполняться только для чтения. Для этого укажите DOTNET_EnableDiagnostics переменную среды как 0 (непосредственно перед ENTRYPOINT шагом):

Создание контейнера

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

Команда docker create выше создает контейнер на основе образа counter-image. В выходных данных этой команды отображается идентификатор контейнера (который будет другим) созданного контейнера:

Управление контейнером

Аналогично, команда docker stop останавливает контейнер. В следующем примере используется команда docker stop для остановки контейнера, а затем — команда docker ps для подтверждения того, что контейнеры не запущены:

Подключение к контейнеру

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

Удаление контейнера

Для этой статьи вы не хотите, чтобы контейнеры не были ничего делать. Удалите созданный ранее контейнер. Если контейнер запущен, остановите его.

В примере ниже выводится список всех контейнеров, Затем с помощью docker rm команды удаляется контейнер, а затем выполняется проверка второго времени для всех работающих контейнеров.

Однократный запуск

Изменение команды ENTRYPOINT

Основные команды

В Docker есть множество различных команд, которые создают контейнеры и образы, управляют ими, а также взаимодействуют с ними. Для управления контейнерами в основном используются такие команды Docker:

Очистка ресурсов

В этом учебнике описано, как создать контейнеры и образы. При желании эти ресурсы можно удалить. Ниже представлены команды, которые позволяют сделать следующее:

Вывести список всех контейнеров.

Остановить запущенные контейнеры по имени.

С помощью команды docker images просмотрите список установленных образов.

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

Источник

Einsteinish/docker-nginx-hello-world

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Single page docker nginx

NGINX webserver that serves a simple page containing its hostname, IP address and port as wells as the request URI and the local time of the webserver.

Now, assuming we found out the IP address and the port that mapped to port 80 on the container, in a browser we can make a request to the webserver and get the page below:

Источник