Pull to refresh

Comments 26

Допустим, я — юнга.

>Директиву CMD можно опустить.

И что в этом случае произойдет?

>Тогда команду, которая исполнится в контейнере, придется указать вручную.

«Вручную» это как? Что нужно сделать, чтобы «указать вручную»?

Из статьи не понятно, чем отличается запуск RUN от CMD. Вроде ж и то, и другое выполняют команду, только у CMD синтаксис какой-то непривычный, не так ли?

>а RUN <shell команда>, которая исполнит любую вашу прихоть команду в контейнере (если она доступна).

А почему она может быть доступна в одном случае, и недоступна в другом? И как ее сделать доступной, если она мне внезапно нужна в конкретном случае, когда она недоступна? Статья на эти вопросы не отвечает.

На мой взгляд на Хабре уже есть более удачные варианты «для юнги».

Спасибо, что прочитали статью и прокомментировали ее. Указанные косяки я исправил. И чуть дополнил моменты с кэшированием.

На тему более удачных вариантов на Хабре и не только. Отразить могу только статью от селектела (https://selectel.ru/blog/what-is-docker/) которой, кстати, здесь нет, и "Понимая docker" (https://habr.com/ru/post/253877/) в которой объясняется принцип работы: namespaces, cgroups и почему на винде для докера все-таки нужна виртуализация (что для джуна, согласитесь, не самая важная информация. Особенно, когда его кидают на проект, где есть какой-то не понятный Dockerfile). Я же попытался сделать выжимку большого количества статей, видосиков по докеру, пропущенную через призму своего восприятия которую, в случае чего, можно юзать, как шпоргалку, поэтому и опубликовал и считаю, что статья имеет место для жизни.

А мне понравилось. Хорошо поданы самые важные моменты, менее важные - упомянуты и гуглятся в два клика. Из десятка статей по самым основам докера, которые мне попадались на хабре - эта пока в топе

" Если бы мне в школе вот так вот... доходчиво... "(с)

"После этого, я загружу файл с зависимостями директивой"\\

Попробуйте упростить статью 

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

Для меня это новое определение клиент-серверной архитектуры. Я всегда всегда имел о ней несколько иное представление.

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

Спасибо большое!
Сегодня перепишу. Действительно звучит как-то неоднозначно (в моей голове явно звучало лучше)

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

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

Ок. Я просто придрался к точности формулировки. )

Да, я тут с вами согласен. Сейчас думаю, как лучше конкретизировать)

Хорошая статья, надо попробовать

Мне не хватило описания, что такое dockerfile, физически. Я конечно загуглил и посмотрел в другой статье, но пара предложений в тексте не повредили бы.

ps совсем юнга

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

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

Аргумент -p <порт контейнера>/<протокол>:<локальный порт>/<протокол>

Если мне не именяет память, то наоборот. сначала протокол и порт локальной машины, потом - контейнера

Не изменяет. Это же и из примера в статье видно. Думаю, автор просто опечатался

Нет, в примере он пишет, что хочет пробросить порт сервера 80 на порт 8080 контейнера. последовательность в примере должна быть обратная, т.е.

-p 80:8080

Да, спасибо! Постоянно путаю и в реальной жизни и здесь.
Забавно, но перепроверил этот момент несколько раз и все-равно напутал xD


UPD: Поправил и дополнил инфой по бинду на конкретный IP

Вопрос, что такое регистр в интерпретации docker?

Вы создали программу для питона app.py. В каком месте вы её поместили в образ докера? И где вы описали момент запуска программы в докере? Почему нигде нет подобной строки для запуска "python3 app.py"?

CMD ["gunicorn", "--bind", "0.0.0.0", "app:app"]

Потому что код запускается не напрямую через интерпретатор питона, а передается на исполнение gunicorn (WSGI сервер)

А код был помещен директивой COPY . .

"Докер - это не виртуальная машина"... и хоба, мы берём образ, содержащий минимальную установку Alpine Linux. Ну и где же этот линукс будет работать? Уж не в виртуальной машине ли?

Ладно бы, если мы гоняли докер на линуксовом хосте. Но на винде и маке нет ядра линукса!

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

Давайте создадим Dockerfile

Это для меня было не понятно. Из вашего текста я понял что мы будем создавать Dockerfile не как имя файла а как файл для Docker. И далее я ожидал увидеть имя для этого файла, для того чтобы прописать строки ниже, но ничего не нашёл.
Это немного ввело в ступор и пришлось гуглить чтобы понять что эти строки пишутся в файл с именем "Dockerfile" в той же директории что и созданные ранее файлы.

Я думаю понятнее будет написать:
Давайте создадим файл с именем "Dockerfile"

Я как раз тот полный юнга по Docker для кого эта статья.

Спасибо! Дополню текст тем, что Dockerfile - это именно название файла.

P.S. Кстати, к статье приложен git-репозиторий с проектом и косвенно это объяснено там

Спасибо! Все максимально подробно и доходчиво.

Sign up to leave a comment.

Articles