Мы начали иметь дело с Docker в третьем квартале/2016 году, преследуя цель его принятия для существующей системной инфраструктуры. К настоящему времени у нас есть несколько производственных приложений, развернутых и работающих в качестве контейнеров Docker. Это довольно хороший подход, помогающий вам внедрить стандарты в окружающую среду и немного проще. У него есть кривая обучения и множество расширенных функций, которые могут довольно быстро вывести вас в путь, потому что вы испытываете желание справиться с ними, даже если они вам не нужны (пока). Не пытайтесь сделать полномасштабную конвейер развертывания контейнеров за один шаг, а скорее старайтесь преобразовать окружающую среду небольшими постепенными шагами. Убедитесь, что вы чувствуете себя в безопасности с каждым приращением, получите опыт работы со всеми вовлеченными вещами, чтобы избежать потери контроля над своими системами после больших изменений. Читайте дальше, чтобы узнать больше …
Что насчет этого?
Контейнеры повсюду, как и Docker, который кажется сущностью и наиболее распространенной из этих технологий на сегодняшний день. Мы начали изучать это всего год назад по разным причинам. Вещи всегда меняются. Наша командная структура изменилась, особенно в отношении разработки и эксплуатации. Количество технических компонентов увеличилось, как и набор различных структур и стеков. Развертывание с другой стороны должно было быть проще не сложнее. Стратегические подходы также изменились, переходя к ИТ -инфраструктуре, основанной на отраслевой группе, с центральным хостингом и командами, отправляющими выделенные услуги общепринятым. Все вместе с этим Докер появился на нашем радаре и остался там.
К настоящему времени у нас есть куча модулей приложений (чтобы на мгновение избежать термина «микросервисы»), поставляемых, отправленных, работающих в среде Docker. Это работает хорошо, он, безусловно, ослабил пару вещей, внедряя новые интересные вопросы для решения. Мы все еще далеки от того, что находимся в полностью автоматической среде непрерывной доставки, где каждый кусок кода автоматически вступает в производство. Каждый инструмент и каждое решение, поддерживаемое технологией, поставляется с кривой обучения, а обработка контейнеров ничем не отличается. Тем не менее, есть уже несколько пониманий, которые мы сделали, понимание, которые я считаю, стоит отметить …
Знай свои проблемы
Несмотря на то, что это звучит явно очевидно, вы должны очень сосредоточиться на выяснении того, какие проблемы вы на самом деле возникают в своей среде, и как контейнеры или более конкретно Docker могут помочь решить. Простая причина заявления об этом: существует множество поставщиков, поставщиков решений и консультантов, пытающихся выяснить, что в конечном итоге может иметь их клиенты, и есть множество поставщиков инструментов, пытающихся продать свое представление о том, как выглядит хорошая контейнерная среда Анкет Точно так же, есть вагоны тематических исследований, белых работ, «лучших практик» и тому подобное, что вам действительно нужно сделать, чтобы быть успешным программным обеспечением для доставки в контейнерах.
Большинство из них совсем не ошибаются. Но в конце вы собираетесь выбрать, действительно ли их решения решают ваши проблемы. Если ваша среда работает отлично хорошо — хорошо. Не влюбляйтесь в такую технологию, как Docker, просто потому, что они могут сделать вещи «еще лучше». Если это не сломано, не исправляйте это.
Тем не менее, наша проблема с проблемой была довольно ясной: мы хотим, чтобы (ЭД) немного развернули процедуры развертывания. Все вместе с переходом от сервера приложений Java EE к нескольким автономным приложениям JVM со встроенными HTTP-серверами некоторое время назад, в какой-то момент мы обменялись сложностью полномасштабного компонента тяжелого сервера со сложностью поддержания и запуска нескольких автономных приложений. Это стало лучше, но, конечно, это оставило пару старых и новых проблем нерешенными. Докер, на первом и втором взгляде, выглядел довольно хорошо, как подход, чтобы решить, по крайней мере, некоторые из этих проблем. Вот почему мы начали вводить Docker для развертывания и работы в первую очередь, явно сосредоточившись на сохранении всего «как есть» для разработчиков. Это достаточно сложная задача — раннее включение разработчиков сделало бы это взорвание.
Установите свои коробки
Одна из лучших вещей Docker может сделать для существующих ИТ-приложений,-это заставлять вас переосмыслить приложения и зависимости. В реальных условиях всегда есть вероятность взаимодействия и зависимости между компонентами и системами, которые не очевидны или документированы просто потому, что никто никогда не думал об этом как о зависимости. Подумайте о простых вещах, таких как ваше приложение, в зависимости от какого -то двоичного файла Linux, который «просто там в/usr/bin» и вызывает из вашего приложения: все в порядке, пока ваше приложение работает на хосте, к которому он был изначально развернут. Будет ли это все еще работать после перехода на другой хост с разными пакетами в разных версиях, установленных в распределении базовой операционной системы? Или в вашем приложении используется установленная сетевая файловая система, которую она ожидала в/носитель, которая теперь, после перехода в новую среду, перемещается в/mnt? Может быть, эти вещи даже подвержены конфигурации в вашем приложении — вы все еще уверены, что это будет очевидно в соответствующей ситуации? Вы уверены, что сможете изящно обрабатывать дополнительные зависимости, введенные в какой -то момент времени?
Обращаясь с Docker, здесь значительно помогло повысить осведомленность об этих проблемах, предоставив эту идею «контейнера». Он заставляет думать о ваших приложениях еще больше как о закрытых ящиках и взаимодействия между приложениями как о связях между этими ящиками, которые необходимо сделать явным для работы. Docker на самом деле не нужен для этого, но он помогает добраться туда, технологически обеспечивая соблюдение этого подхода контейнера, а также путем предоставления способов описания зависимостей, связи между приложениями,…: Базовое изображение, используемое для вашего контейнера, описывает, какие либеральной системы и двоичные файлы будут рядом. Объемные объемы, установленные и порты, выявленные вашим контейнером, описывают некоторые из его интерфейса. Используя что-то вроде Docker-Compose, вы сможете также более строго описывать зависимости между контейнерами (в каком порядке им нужно начать работать, как они связаны,…).
Опять же: это не нужно, чтобы Docker действительно не нужен, но это тот момент, когда это определенно помогает выполнить какую -то работу, которую ИТ -организации должны будут делать в любом случае.
Начни безопасно и быстро
В наши дни люди говорят о «инфраструктуре как коде». Если это так (и я думаю, что это действительно хорошая идея в некотором смысле), мы также должны применять те же правила, которые мы хотим применить к разработке программного обеспечения, которые должны быть гибкими, в целом: сосредоточиться на предоставлении видимой ценности в коротких итерациях, попытаться Постепенно улучшитесь, старайтесь начать где-нибудь, учиться в реальных случаях использования в производственных средах, улучшится. Перевод этого подхода в развертывание на основе Docker, рекомендация будет: убедитесь, что вы быстро перейдите от простой теории в рабочую среду. Выберите кандидата в заявку, узнайте, как создать из него изображение, научитесь запустить это изображение в контейнере. Получите это работать в производстве и убедитесь, что у всех в вашей команде OPS есть идея справиться с этим, даже когда вы уезжаете в отпуск.
Почему? Что ж, с полномасштабной средой с, скажем, Docker, выделенными операционными системами, такими как CoreoS, инструменты оркестровки, такие как Kubernetes, возможно, сервисы конфигурации, такие как ETCD или локальные или удаленные реестры Docker, вы очень быстро получите слишком много новых вещей. Представьте свою среду. Существует множество изменений, которые, скорее всего, нарушат существующие рабочие процессы для соответствующих заинтересованных сторон в вашей ИТ -организации. Ваши операции люди должны научиться управлять и привыкать ко всему этому, и пока они это делают, стабильность вашей системы подвержена риску.
Не делай этого. Попробуйте найти минимальный значимый прирост и вытащить его и работать как можно быстрее. В нашем случае это было все о расширении нашей текущей процедуры развертывания на основе общих инструментов, таких как…
- SSH/SCP для копирования артефактов между различными серверами,
- Сценарии Bash для запуска/остановки/обновления двоичных файлов в условиях тестирования и производства,
- Артефакты ZIP для отправки двоичных файлов, сценариев запуска/остановки и минимальных файлов конфигурации,
- Stock Ubuntu/Debian Servers для запуска компонентов и
- Локальный сервер Gitlab и Gitlab-Ci для создания «обычных» артефактов Java/Maven и изображений Docker All Alike
Работать с изображениями Docker CLI и Docker, хранящиеся в файлах. Первоначально мы работаем даже без локального или центрального реестра докеров и просто используем Docker Load и Docker Save для сохранения изображений в файлы и загрузки их снова на серверах Docker. Сами контейнеры Docker работают на одних и тех же стандартных серверах Ubuntu, что и раньше, бок о бок с существующими приложениями. Контейнеры Docker по -прежнему останавливаются и перезапускаются с помощью сценариев Bash.
Он не может стать более голым, чем это, но это работает. Это до сих пор ничего не меняет для разработчиков. Это мало меняется для операций, ребята. Но это уже предоставляет несколько преимуществ, включая изучение контейнеров, файлы журналов,… использование пользовательского интерфейса Portainer на веб -странице или быть более легким для возврата в старые версии производственного кода на живых серверах. Этого достаточно для оперативных людей, чтобы оправдать дело с этим, и все же изменение, введенное таким образом, приемлемо.
Масштаб хорошо
Если вы сделали это здесь, остальная часть, возможно, будет довольно тривиальной-по существу: повторно обратитесь. Найдите то, что вы больше всего разбираете в статус -кво, вы только что достигли, выясните, как улучшить, и на самом деле улучшить еще один маленький шаг. Возможно, предоставление вашей ИТ -командам некоторое время, чтобы познакомиться с новой структурой и собрать отзывы о том, что должно быть следующим шагом, является хорошей идеей, даже если у вас есть четкая повестка дня, в которой вы хотите двигаться. В нашем случае несколько следующих шагов, которые кажутся желательными и необходимыми, являются…
- … Использование или принятие внутреннего реестра докеров для лучшей обработки изображений,
- … Работать с сценариями конфигурации и запуска контейнера/остановки умнее,
- … Учитывая способ решения и предоставления больших двоичных файлов данных в лучшем виде, чем при необходимости монтировать CIFS совместно на все серверы. У нас есть пара идей для каждого из них, но ни приоритеты, ни реальные решения не допускаются по этому поводу. Давайте посмотрим, куда все это движется, может быть, я вспомню в ближайшем будущем, если стоит отметить что -то. Следите за обновлениями.
Пост скриптум
Возможно, есть нагрузка больше, чтобы написать об этом, но в какой -то момент кому -то потребуется прочитать все это, поэтому я буду держать это в этом и подробно расскажу, если кто -то заинтересован. Однако выводы до сих пор: тратить довольно на некоторые из офисов, а также свободное время на Docker и контейнеры до сих пор окупились, даже если есть множество вещей, которые можно улучшить. Лично, глядя на эти вещи, я обнаружил отличную информацию и развлечения в прослушивании подкастов и чтения книг и статей о DevOps и Agile Development Software одновременно. Я обнаружил, что большинство разработчиков (ну, включая меня время от времени), скорее всего, будут настаивать на отличных, насыщенных функциях новых выпусков или новых технологий или новых каркасов и стеков со всеми наколками, свистками и кухонной раковиной в наши дни. В то же время я прекрасно понимаю каждого парня -эксплуатации, который должен придерживаться более консервативной точки зрения для того, чтобы сохранить какие -либо изменения в производственную среду максимально небольшую, насколько это возможно (или, самое главное, избегать их), зная, что это изменение враг стабильности. Гибкое развитие и культура DevOps кажутся хорошим способом разрешения этого «конфликта», хотя и не простым способом по нескольким причинам. Но это другое дело …
Первоначально опубликовано В моем блоге
Оригинал: «https://dev.to/kr428/shipping-containers-lessons-learnt-from-adopting-docker»