ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

5 минут чтени€

DevOps

≈сли ¬ы наконец пон€ли, что повсюду окружены контейнерами и обнаружили, что они решают массу проблем и имеют много преимуществ:

  1.  онтейнеры вездесущи - ќ—, версии библиотек, конфигурации, папки и приложени€ помещаютс€ в контейнер. ¬ы гарантируете, что та же сама€ задача, котора€ была протестирована в QA, достигнет производственной среды с таким же поведением.
  2.  онтейнеры упрощены - объем пам€ти контейнера невелик. ¬место сотен или тыс€ч мегабайт контейнер будет выдел€ть пам€ть только дл€ основного процесса.
  3.  онтейнеры быстрые - ¬ы можете запустить контейнер дл€ начала работы так же быстро, как типичный процесс Linux. ¬место минут можно запустить новый контейнер за несколько секунд.

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

ћантра о контейнерах: У онтейнеры эфемерныФ.

Ёта характеристика заставл€ет пользователей помен€ть свое мышление относительно того, как они должны обращатьс€ с контейнерами и управл€ть ими; и € объ€сню, чего Ќ≈ следует делать, чтобы продолжать извлекать наилучшие преимущества контейнеров.


10 вещей, которых следует избегать в Docker контейнерах

  1. Ќе хранить данные в контейнерах - контейнер может быть остановлен, удален или заменен. ѕриложение версии 1.0, работающее в контейнере, может быть легко заменено версией 1.1 без какого-либо неблагопри€тного воздействи€ или потери данных. ѕоэтому, если нужно сохранить данные, сделайте это на диске. ¬ этом случае следует также позаботитьс€ о том, чтобы два контейнера записывали данные на один и тот же диск, что может привести к повреждению. ”бедитесь, что приложени€ могут записывать данные в хранилище объектов.
  2. Ќе раздел€ть свое приложение на две части - так как некоторые люди вид€т контейнеры в роли виртуальной машин и поэтому большинство из них склонны думать, что они должны примен€ть свое приложение только в существующих работающих контейнерах. Ёто может быть справедливо на этапе разработки, на котором ¬ам необходимо непрерывно разрабатывать и налаживать процесс; но дл€ непрерывной доставки (CD) в QA и производства, ¬аше приложение должно быть частью образа. ѕомните:  онтейнеры нельз€ изменить.
  3. Ќе создавать большие образы - большой образ будет труднее распространить. ”бедитесь в наличии только необходимых файлов и библиотек дл€ запуска приложени€/процесса. Ќе устанавливайте ненужные пакеты и не запускайте обновлени€ (yum update), которые загружают много файлов на новый слой образы.
  4. Ќе использовать однослойный образ - чтобы эффективно пользоватьс€ многоуровневой файловой системой, всегда создавайте собственный базовый слой образы дл€ операционной системы, а также другой слой дл€ определени€ имени пользовател€, слой дл€ установки во врем€ выполнени€, слой дл€ конфигурации и, наконец, слой дл€ приложени€. Ѕудет проще воссоздать образ, управл€ть им и использовать его.
  5. Ќе создавать образы из запущенных контейнеров - другими словами, не используйте слово docker commit дл€ создани€ образа. Ётот способ не приносит пользы, и его следует полностью избегать. ¬сегда используйте полностью воспроизводимый Dockerfile или любой другой S2I (от источника к изображению) подход, и ¬ы можете отследить изменени€ в Dockerfile, если сохранить его в хранилище системы управлени€ верси€ми (git).
  6. Ќе использовать latest (последний) тег Ц он подобен SNAPSHOT дл€ пользователей Maven. ћетки подключаютс€ из-за слоистой файловой природы контейнеров. ¬ы ведь не хотите иметь сюрпризы при построении образа несколько мес€цев, а потом вы€снить, что приложение не может быть запущено, так как родительский слой (из-за Dockerfile) был заменен новой версией, котора€ не €вл€етс€ обратно совместимой, или из кэша сборки была получена неправильна€ "последн€€" верси€. “ега latest также следует избегать при применении контейнеров в производстве, так как невозможно отследить, кака€ верси€ образа выполн€етс€.
  7. Ќе выполн€ть более одного процесса в одном контейнере - контейнеры идеально подход€т дл€ выполнени€ лишь одного процесса (HTTP, сервер приложений, база данных), но если имеетс€ более одного процесса, могут возникнуть дополнительные проблемы с управлением, извлечением журналов и обновлением их по отдельности.
  8. Ќе хранить учетные данные в виде образов. »спользуйте переменные среды, ведь дл€ этого не требуетс€ жестко кодировать им€ пользовател€/пароль в образе. »спользуйте переменные среды дл€ получени€ этой информации вне контейнера. ќтличный пример этого принципа - образ ѕостгреса.
  9. Ќе запускать процессы от имени пользовател€ root - "ѕо умолчанию docker контейнеры выполн€ютс€ от имени пользовател€ root. ѕо мере Ђвзрослени€ї docker контейнеров могут стать доступны секретные по умолчанию параметры. Ќа данный момент требуемый root опасен дл€ других и может быть доступен не во всех средах. ¬аш образ должен использовать инструкцию USER, чтобы указать пользовател€, не €вл€ющегос€ root, дл€ контейнеров, которые будут запускатьс€".
  10. Ќе полагайтесь на IP-адреса - каждый контейнер имеет свой собственный внутренний IP-адрес, и он может изменитьс€, если вы запустите и остановите контейнер. ≈сли приложению или микросервису требуетс€ св€зь с другим контейнером, используйте переменные среды дл€ передачи соответствующего имени хоста и порта из одного контейнера в другой.