Сообщение Re: что хорошего в docker'е? от 17.11.2017 20:24
Изменено 17.11.2017 20:28 scf
Re: что хорошего в docker'е?
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого?
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Докер — это явление, по масштабам не уступающее гиту, только в сисадминстве.
Основной его бонус — инкапсуляция и сетевое хранилище образов.
К любому крупному приложению обычно прилагается документ с n (n >= 10) пунктов, которые надо выполнить перед тем, как попытаться это приложение запустить. Докер заменяет всё это безобразие однострочником.
Раньше приложения зиповали и заливали в Nexus — сейчас их собирают и заливают в докер. Разница в том, что зип надо как-то распаковать, настроить, дотащить зависимости (ту же java в простейшем случае) — в образе докера всё это уже есть, причем с дедупликацией.
Раньше запуск приложения 1-2-3 летней давности был очень нетривиальной задачей — с докером шанс успеха очень высок, т.к. все зависимости и системные библиотеки упакованы внутри образа.
Раньше для приложений делали всякие-разные лаунчеры, прописывали их в init.d, извращались как могли, чтобы они автоматически перезапускались при краше или рестарте сервера. Докер делает это лучше, сам и без внесения изменений в настройки хоста.
Немного советов от опытного пользователя докера)
— только Linux. Желающие заниматься разработкой серверного ПО под другими осями — страдают или не используют докер
— --net=host — единственный правильный вариант, маппинг портов и всё это докеровское безобразие с сетевыми драйверами — не нужно
— приложение должно настраиваться через переменные окружения (env variables) и, в тяжелых случаях, файлами
— приложение должно внятно писать, какие переменные окружения ему нужны, какие забыли указать, и какие вообще оно понимает
— в приличном приложении все слушающие порты должны настраиваться (см. пункт про --net=host)
— volumes ненужная фигня — лучше просто маппить каталоги наружу. Мы делаем -v /data:/data/$image_name
— приложение должно само редиректить stdout в файл — доверять стандартному docker logging driver нельзя — он кривой
— docker compose и т.п. фигня — на одной машине проще на баше примитивный скрипт родить, а в кластере все равно kubernetes/consul/велосипед
M>что в нём хорошего? и что плохого?
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Докер — это явление, по масштабам не уступающее гиту, только в сисадминстве.
Основной его бонус — инкапсуляция и сетевое хранилище образов.
К любому крупному приложению обычно прилагается документ с n (n >= 10) пунктов, которые надо выполнить перед тем, как попытаться это приложение запустить. Докер заменяет всё это безобразие однострочником.
Раньше приложения зиповали и заливали в Nexus — сейчас их собирают и заливают в докер. Разница в том, что зип надо как-то распаковать, настроить, дотащить зависимости (ту же java в простейшем случае) — в образе докера всё это уже есть, причем с дедупликацией.
Раньше запуск приложения 1-2-3 летней давности был очень нетривиальной задачей — с докером шанс успеха очень высок, т.к. все зависимости и системные библиотеки упакованы внутри образа.
Раньше для приложений делали всякие-разные лаунчеры, прописывали их в init.d, извращались как могли, чтобы они автоматически перезапускались при краше или рестарте сервера. Докер делает это лучше, сам и без внесения изменений в настройки хоста.
Немного советов от опытного пользователя докера)
— только Linux. Желающие заниматься разработкой серверного ПО под другими осями — страдают или не используют докер
— --net=host — единственный правильный вариант, маппинг портов и всё это докеровское безобразие с сетевыми драйверами — не нужно
— приложение должно настраиваться через переменные окружения (env variables) и, в тяжелых случаях, файлами
— приложение должно внятно писать, какие переменные окружения ему нужны, какие забыли указать, и какие вообще оно понимает
— в приличном приложении все слушающие порты должны настраиваться (см. пункт про --net=host)
— volumes ненужная фигня — лучше просто маппить каталоги наружу. Мы делаем -v /data:/data/$image_name
— приложение должно само редиректить stdout в файл — доверять стандартному docker logging driver нельзя — он кривой
— docker compose и т.п. фигня — на одной машине проще на баше примитивный скрипт родить, а в кластере все равно kubernetes/consul/велосипед
Re: что хорошего в docker'е?
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого?
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Докер — это явление, по масштабам не уступающее гиту, только в сисадминстве.
Основной его бонус — инкапсуляция и сетевое хранилище образов.
К любому крупному приложению обычно прилагается документ с n (n >= 10) пунктов, которые надо выполнить перед тем, как попытаться это приложение запустить. Докер заменяет всё это безобразие однострочником.
Раньше приложения зиповали и заливали в Nexus — сейчас их собирают и заливают в докер. Разница в том, что зип надо как-то распаковать, настроить, дотащить зависимости (ту же java в простейшем случае) — в образе докера всё это уже есть, причем с дедупликацией.
Раньше запуск приложения 1-2-3 летней давности был очень нетривиальной задачей — с докером шанс успеха очень высок, т.к. все зависимости и системные библиотеки упакованы внутри образа.
Раньше для приложений делали всякие-разные лаунчеры, прописывали их в init.d, извращались как могли, чтобы они автоматически перезапускались при краше или рестарте сервера. Докер делает это лучше, сам и без внесения изменений в настройки хоста.
Немного советов от опытного пользователя докера)
— только Linux. Желающие заниматься разработкой серверного ПО под другими осями — страдают или не используют докер
— --net=host — единственный правильный вариант, маппинг портов и всё это докеровское безобразие с сетевыми драйверами — не нужно
— приложение должно настраиваться через переменные окружения (env variables) и, в тяжелых случаях, файлами
— приложение должно внятно писать, какие переменные окружения ему нужны, какие забыли указать, и какие вообще оно понимает
— в приличном приложении все слушающие порты должны настраиваться (см. пункт про --net=host)
— volumes ненужная фигня — лучше просто маппить каталоги наружу. Мы делаем -v /data:/data/$image_name
— приложение должно само редиректить stdout в файл — доверять стандартному docker logging driver нельзя — он кривой
— docker compose и т.п. фигня — на одной машине проще на баше примитивный скрипт родить, а в кластере все равно kubernetes/consul/велосипед
— не нужно извращаться с юзерами под докером — в контейнере можно запускать всё из-под рута. Все равно из контейнера ему не деться, про дыры в безопасности "изнутри" я не слышал, а при желании kernel capabilities можно еще сильнее урезать.
M>что в нём хорошего? и что плохого?
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Докер — это явление, по масштабам не уступающее гиту, только в сисадминстве.
Основной его бонус — инкапсуляция и сетевое хранилище образов.
К любому крупному приложению обычно прилагается документ с n (n >= 10) пунктов, которые надо выполнить перед тем, как попытаться это приложение запустить. Докер заменяет всё это безобразие однострочником.
Раньше приложения зиповали и заливали в Nexus — сейчас их собирают и заливают в докер. Разница в том, что зип надо как-то распаковать, настроить, дотащить зависимости (ту же java в простейшем случае) — в образе докера всё это уже есть, причем с дедупликацией.
Раньше запуск приложения 1-2-3 летней давности был очень нетривиальной задачей — с докером шанс успеха очень высок, т.к. все зависимости и системные библиотеки упакованы внутри образа.
Раньше для приложений делали всякие-разные лаунчеры, прописывали их в init.d, извращались как могли, чтобы они автоматически перезапускались при краше или рестарте сервера. Докер делает это лучше, сам и без внесения изменений в настройки хоста.
Немного советов от опытного пользователя докера)
— только Linux. Желающие заниматься разработкой серверного ПО под другими осями — страдают или не используют докер
— --net=host — единственный правильный вариант, маппинг портов и всё это докеровское безобразие с сетевыми драйверами — не нужно
— приложение должно настраиваться через переменные окружения (env variables) и, в тяжелых случаях, файлами
— приложение должно внятно писать, какие переменные окружения ему нужны, какие забыли указать, и какие вообще оно понимает
— в приличном приложении все слушающие порты должны настраиваться (см. пункт про --net=host)
— volumes ненужная фигня — лучше просто маппить каталоги наружу. Мы делаем -v /data:/data/$image_name
— приложение должно само редиректить stdout в файл — доверять стандартному docker logging driver нельзя — он кривой
— docker compose и т.п. фигня — на одной машине проще на баше примитивный скрипт родить, а в кластере все равно kubernetes/consul/велосипед
— не нужно извращаться с юзерами под докером — в контейнере можно запускать всё из-под рута. Все равно из контейнера ему не деться, про дыры в безопасности "изнутри" я не слышал, а при желании kernel capabilities можно еще сильнее урезать.