12 друзей Docker-а – опенсорсные инструменты в помощь разработке


Оглавление (нажмите, чтобы открыть):

Знакомимся с основными возможностями Docker

Docker — это действительно Must Have инструмент для разработчика и администратора любого крупного проекта. И даже если это не так, Docker всё равно необходимо знать. Ведь уже в ближайшем будущем он будет везде, начиная от десктопного Linux-дистрибутива и заканчивaя пулом серверов на AWS. А разобраться с ним довольно лeгко, если, конечно, правильно понимать принцип его работы.

На мастер-классе обсудим:

Что такое Docker;

Преимущества перед LXC и классической виртуализацией;

Основные концепции Docker на простых примерах из жизни

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

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

На что это похоже?

Контейнер

Как и обычный пластиковый контейнер, Docker-контейнер обладает следующими характеристиками:

  1. Хранит вещи.
  2. Портативен — вы можете пользоваться им и на вашем компьютере, и на компьютере коллеги, и в облачных сервисах, таких как Amazon Web Services.
  3. Имеет удобный интерфейс — у нашего пластикового контейнера есть крышка, разделяющая вещи внутри него и снаружи. У Docker’а точно так же есть некоторые механизмы, позволяющие взаимодействовать с внешним миром. У него есть порты для взаимодействия через браузер. Вы можете настроить его для работы с данными через консоль.
  4. Может быть создан повторно — вы можете взять другой пустой пластиковый контейнер, если он вам понадобится, поскольку есть фабрики, которые выпускают их тысячами. В случае с Docker-контейнером сервисы и пользователи хранят образы контейнеров, которые позволяют быстро развернуть необходимую среду.

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

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

4 октября 2020 – 1 марта 2020, Москва и онлайн, беcплатно

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

Некоторые термины

Виртуальная машина

Docker чем-то схож с виртуальной машиной. Но всё же это больше средство виртуализации процессов, а не систем.

Образ

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

Формочки для выпечки

Образ содержит в себе Docker-файл, все необходимые зависимости для вашего приложения и непосредственно само ваше приложение.

Docker-файл

Docker-файл — инструкции для Docker по настройке и запуску приложений. В Docker-файле находится описание базового образа, на котором построен контейнер. Одни из самых популярных образов — Python, Ubuntu и Alpine.

С помощью дополнительных слоёв в Docker-файле можно добавить необходимое ПО. Например, можно указать, что Docker’у нужно добавить библиотеки NumPy, Pandas и Scikit-learn.

Docker-контейнер

Docker-образ плюс команда docker run image_name создадут и запустят контейнер по образу.


Реестр контейнеров

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

Приготовление

  • Docker-файл описывает, что нужно делать с контейнером. Это похоже на рецепт приготовления блюда.
  • Docker-файл содержит слои. Если проводить аналогию с пиццей, то слоями будут тесто, сыр и приправы, т. е. ингредиенты.

Рецепт и ингредиенты— необходимые условия для приготовления пиццы. В экосистеме Docker — это Docker-образ.

Рецепт (Docker-файл) описывает действия:

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

Итак, всё подготовлено, приступим.

  • Духовка, в которой готовится пицца, — это Docker-платформа. Вы устанавливаете духовку, когда въезжаете в дом, и уже можете в ней печь. Так и с Docker: вы устанавливаете его к себе на компьютер и можете создавать контейнеры.
  • Чтобы включить духовку, вы нажимаете кнопку. Команда docker run [] запускает контейнер.
  • Приготовленная пицца — это Docker-контейнер.
  • Поедание пиццы — это использование вашего приложения.

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

Появился новый опенсорсный ML-фреймфорк Streamlit для разработки приложений

Новый стартап Streamlit, основанный выходцами из GoogleX и Zoox, запустил гибкий опенсорсный инструмент, который упрощает разработчикам машинного обучения создание кастомных приложений для взаимодействия с данными в моделях, пишет TechCrunch.

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

«Уникальность Streamlit в том, что в отличие от большинства компаний, которые пытаются систематизировать ту или иную часть рабочего процесса, мы даём ML-инженерам что-то вроде конструктора Lego, из которого можно создать что угодно», — поясняет сооснователь Streamlit Эдриэн Трель.

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

По его словам, всего за несколько строк кода ML-разработчик cможет начать создавать инструменты для понимания данных и взаимодействовать с ними любым необходимым образом исходя из их особенностей и «за полдня выполнить проект, который бы потребовал 4 недели и 15 тысяч строк кода».

Streamlit помогает строить инструменты для понимания огромных объёмов данных быстрее и с помощью привычных средств программирования. По мнению команды, инструментарий может кардинально изменить подход инженеров машинного обучения к работе с данными в моделях.

Стартап получил $6 млн посевных инвестиций, раунд возглавили Gradient Ventures при участии Bloomberg Beta, основатели #Angels, Color Genomics и Docker, а также партнёр Y Combinator Дэниэл Гросс.

1. Заполните анонимную форму — 5 минут.
2. Укажите зарплатные (и другие) ожидания.
3. Выберите желаемую индустрию или область деятельности.
4. Получайте релевантные предложения​​.​​​​

Как должен выглядеть процесс работы с Docker?

После длительных и постоянных мучений в ручном развертывании приложений на сервера для тестов и продакшена, у меня на работе появилось желание в автоматизации этого процесса.
Я обычный разработчик и с DevOps связан косвенно. Опыта в этом немного, а отдельного специалиста у нас для этого нет. Поэтому приходиться брать все в свои руки.
Сейчас у нас есть несколько приватных проектов, состоящие из бэкенда и фронтенда. По масштабу проекты не большие. Бэкенд создан на стеке NodeJS + MongoDB + ElasticSearch + Redis.


Что бы автоматизировать процесс развертывания, начал изучать Docker. Но столкнулся с некоторым непониманием как все должно работать. В основном все материалы в сети отвечают на вопрос: Что такое Docker? И лишь малая часть отвечает на вопрос: Как с ним работать? И даже в них все процессы описываются поверхностно.

Я разобрался с Docker клиентом и поднял docker-machine. Понял как устанавливать образы с Docker Hub и запускать контейнеры. А дальше все. Тупик.
Возникло много вопросов, что делать дальше?
Как мне создать свой контейнер состоящий из образов NodeJs, MongoDB, ElasticSearch, Redis?
Где это все хранить?
Как мне расшарить папки проектов для Docker?
Как мне это интегрировать с CI и CD?
Я запутался. Возникают мысли, а нужно ли мне это? Может все таки по старинке деплоить через FTP?

В общем прошу помощи разобраться в том, как должен быть построен процесс развертывания проектов на Docker?
Или поделиться материалами, где на практике показано что и как нужно делать.

  • Вопрос задан более двух лет назад
  • 9472 просмотра

по старинке деплоить через FTP

Как я понимаю мне тогда придется подключаться по ssh к каждому серверу и обновлять там все нужные репозитории проектов

Рамиль:
Конечно, придётся подключаться по SSH.
Но по FTP же вы тоже подключаетесь?
В самом-самом простом случае, даже без Докера/CI/CD, у вас на сервере будут 2 просто неоценимые возможности:
1. Одной командой git pull затянуть все обновления.
2. Одной командой git checkout откатиться на предыдущий стабильный коммит, если что-то пойдёт не так.

Что касается сборки фронта — не знаю, как лучше, но, как минимум, можно после заливки Git-ом дать ещё одну команду, gulp build или что там у вас

Попробую описать простыми словами без серьезной терминологии (Devops’ы не бейте ногами).

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

Например у нас такая структура. Я использую php но для nodejs может быть похоже.

Настраивается взаимодействие в специальном файле.

Теперь использовав docker-compose up мы удобно запустим все контейнеры с нужной конфигурацией.
Взаимодействие между контейнерами будет происходить по алиасам
например из php соединение с БД происходит так:

Код прокидываем в 2 контейнера php и nginx (раздел volumes). То есть внутри контейнера создается директория /app которая ссылается на директорию на хост машине. Для разработки очень удобно, вы изменяете код и сразу можно обновлять страницу.

На продакшен я обновляю код через git из репозитория и перезапускаю контейнеры (если надо).

ps. Это один из самых простых способов, разумеется существуют более «взрослые» и «правильные» методы. Но надеюсь мое описание позволит вам сдвинутся с мертвой точки в изучении докера.

paldraken спасибо, будет очень круто, если приведете хотя бы часть своего рабочего файла docker-compose под винду
а то вроде все варианты с путями обыграл, но так и остался ни с чем)

У меня всё нормально пробрасывается даже с относительными путями:

Для этого надо в настройках докера в Shared Drives добавить галочку напротив вашего диска

tupen: а что не так с БД в докере?
добавьте, если можно, конкретики.
по вашей ссылке только общие проблемы докера на дебиане.

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

https://habrahabr.ru/post/332450/#comment_10298132
AndrewFoma 5 июля 2020 в 01:28
# Короче. Докер НЕ ДОЛЖЕН ЗАПУСКАТЬ базы данных в продакшене, by design.
более 100 с чем то серверов(изолированных друг от друга), всё в продакшене, есть очень нагруженные узлы (4 сервера в кластере), ну так 600 млн. записей в базу в сутки, записи — строки(в среднем 200-300 символов), всё работает через докер. Я не знаю, что у вас там, может железо.

+ есть успешный опыт в не очень крупных проектах, примерно раза в два поменьше(в праймтайм) чем у юзернейма AndrewFoma.

а скорость тестов новых версий mysql со своей базой на баги и регрессии?
а удобство отката на прошлую версию окружения если в новой что то пошло не так?

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


как я понял по ответам тут собрались адепты докера. В этой церкви последователь должен появиться атеист. Только сегодня был большой срач насчет какие проблемы можно получить при переходе на докер https://habrahabr.ru/post/332450/ очень советую почитать.

Теперь к вашему вопросу. Докер НЕЛЬЗЯ использовать для персистентный образов. Т.к. если его правильно готовить никакой уверенности нет на какой ноде будет запускаться ваш контейнер физический. Т.е. все что пишет в память или на диск нельзя оборачивать в докер контейнер. Потом есть системы оркестрации, которые ваш контейнер могут с одной ноды на другую перебросить, что вы думаете будет с памятью контейнера — правильно, она очистится.

Тут мне могут возразить что у нас все работает на «отлично» — это вы господа с проблемами не сталкивались. Читаем статью по ссылке выше и начинаем готовиться.

Давайте разберем ваш стек и посмотрим что можно упаковать в докер контейнер.
— NodeJS — не знаю как это у вас работает, если нет состояния — то можно
— MongoDB — база, пишет в файлы, однозначно нельзя
— ElasticSearch — этого зверя точно нельзя он и в память и на диск пишет
— Redis — пишет в память, точно нельзя

И что в итоге вы хотите обернуть в контейнер? И зачем вам докер? Чтоб mongodb была запущена от имени root? При этом мы помним о проблемах с безопасностью самой mongodb. Или elasticsearch завернуть в докер, он физический сервер способен утилизировать на 100% по памяти, пропускной способности дисковой подсистемы и 100% процессорного времени, а вы ему хотите еще один уровень абстракции в лице докера? ))

Одно дело на компьютере разработчика использовать docker-composer и совсем другое дело в продакшене.

Мастер Йода рекомендует:  Как Linux помог мне стать продвинутым пользователем ПК

Четыре класса задач, для которых Docker подходит идеально

Содержание статьи

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

Есть четыре класса задач, для которых Docker подходит если не идеально, то лучше любого другого инструмента. Это:

  • Упрощение процесса разворачивания/сопровождения проектов. Docker позволяет разбить проект на небольшие независимые, удобные в сопровождении компоненты, работать с которыми гораздо комфортнее, чем с реальными сущностями вроде Apache 2.4.12, установленного на хосте 1.2.3.4, работающем под управлением CentOS 6.
  • Continous development и zero-downtime deployment. Каждый образ Docker — вещь в себе, включающая сервис (или набор сервисов), окружение для его запуска и необходимые настройки. Поэтому контейнеры можно передавать между членами команды в ходе цикла «разработка -> тестирование -> внедрение» и быстро внедрять изменения, просто переключая настройки на новые контейнеры.
  • IaaS/PaaS. Благодаря легковесности контейнеров Docker можно использовать в качестве движка виртуализации в IaaS, а благодаря простоте миграции Docker становится идеальным решением для запуска сервисов в PaaS.
  • Запуск небезопасного кода. Docker позволяет запустить любой, в том числе графический софт внутри изолированного контейнера с помощью одной простой команды. Поэтому он идеально подходит для запуска разного рода недоверенного или просто небезопасного кода.

В следующих разделах мы рассмотрим все четыре применения Docker с простыми и не очень примерами.

Кейс номер 1. Поднимаем LAMP

В качестве примера разбиения приложения на составные компоненты рассмотрим пример LAMP + WordPress. Это абсолютно стандартная настройка, за тем исключением, что ее компоненты будут работать в обособленных контейнерах. А это, в свою очередь, позволит нам: а) обезопасить хост-систему и другие контейнеры в случае проникновения в один из них; б) получить возможность легко масштабировать нашу инсталляцию, разнеся ее компоненты по разным машинам; в) выполнить миграцию с помощью пары простых команд; г) упростить обкатку новых версий nginx, PHP или MySQL.

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

Теперь делаем commit, чтобы создать новый образ. Назовем его centos:updated:

На основе нашего обновленного образа создадим два новых. Один — для запуска Apache и PHP (к сожалению, мы не сможем разнести их по разным контейнерам по сугубо техническим причинам), второй — для MySQL. Начнем с Apache:

Добавляем IP-адрес и имя хоста в /etc/hosts и редактируем конфиг Apache, указав имя хоста и web root:

Пробуем открыть адрес 172.17.0.20 в браузере в хост-системе, должна появиться стандартная страничка phpinfo(). Если это так — все ОK, можно закоммитить изменения в новый контейнер:

Теперь настроим контейнер с MySQL с выносом базы данных на хост-систему (мы же не хотим потерять ее после остановки контейнера):

Создаем базу данных и юзера, как показано на скриншоте «Создаем базу данных», после чего — новый контейнер:

Создаем базу данных

Хакер #196. Все о Docker


Смотрим, что у нас получилось:

Теперь нам необходимо установить WordPress, и здесь у нас есть два пути: мы можем вновь запустить контейнер example:www и распаковать архив WordPress в каталог /var/www/html/ внутри него либо можем распаковать его в какой-нибудь каталог на хост-системе и просто смонтировать его внутрь контейнера при запуске. Первый способ позволяет с удобством таскать контейнеры между машинами, второй более удобен при разработке веб-приложений. Для примера пойдем по второму пути. Итак, скачиваем и распаковываем WordPress в каталог /root/html/ на хост-системе:

Все. Теперь осталось только запустить контейнеры с правильными опциями:

Открываем в браузере адрес контейнера www и видим инсталлятор WordPress.

Два работающих контейнера: Apache/PHP + MySQL Запущенный WordPress

Кейс номер 2. Отлаживем, тестируем, внедряем

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

Однако здесь тебя ждет небольшая проблема, и заключается она в том, что для замены одного контейнера на другой придется вручную перенастраивать все зависимые от него контейнеры. А это, во-первых, не очень-то и удобно, а во-вторых, требует времени. Решить эту проблему можно разными средствами, в том числе встроенным в Docker механизмом линковки (о нем мы поговорим в следующей статье), но он имеет ряд проблем, поэтому лучше будет воспользоваться множество раз обкатанной в продакшене системой DNS discovery на основе связки SkyDNS и Skydock.

Основная идея этого метода состоит в том, чтобы поднять локальный DNS-прокси SkyDNS и приложение Skydock, которые, работая в тандеме, будут автоматически назначать контейнерам локальные хостнеймы, основанные на имени образа и контейнера Docker. Как следствие, контейнер с обновленным образом того же MySQL из примера выше можно будет включить в общую настройку, просто запустив его, а затем остановив «старый» контейнер. И все это без дополнительных настроек.

Чтобы добавить SkyDNS к уже существующей конфигурации (возьмем для примера все тот же LAMP), достаточно выполнить несколько команд. Для начала установим и запустим сам SkyDNS:

Здесь все довольно просто: с помощью опции -p мы пробрасываем порт 53 с виртуального сетевого моста внутрь контейнера SkyDNS (172.17.42.1 — дефолтовый IP-адрес моста docker0, создаваемого демоном Docker), а с помощью опции -nameserver самого SkyDNS указываем fallback DNS-сервер, который будет использован для резолвинга глобальных хостнеймов. Последняя опция, -domain задает имя домена первого уровня для локальных хостнеймов.

Далее необходимо запустить Skydock. Здесь все еще проще:

Здесь мы с помощью опции -v пробрасываем в контейнер UNIX-сокет Docker, необходимый Skydock для получения уведомлений о запуске и остановке контейнеров и их имен, а далее идет несколько опций самого Skydock:

  • -ttl 30 — время жизни DNS-записи в секундах;
  • -environment dev — имя домена второго уровня для контейнеров;
  • -s /docker.sock — путь до проброшенного ранее сокета;
  • -domain docker — домен первого уровня;
  • -name skydns — имя контейнера со SkyDNS.

Это все. Теперь, если перезапустить контейнеры с Apache и MySQL из предыдущего примера, то они получат имена www.dev.docker и mysql.dev.docker (а если бы мы дали им имена, то они бы стали доменами четвертого уровня). В ситуации с LAMP это нам ничего не даст, кроме чуть большего удобства управления, но в более сложной конфигурации со множеством различных сервисов позволит на лету менять контейнеры (запускаем новый, завершаем старый, никаких настроек, главное, чтобы имена образов и контейнеров совпадали) и даже балансировать нагрузку — SkyDNS будет отдавать IP-адреса с одинаковым именем хоста по очереди, в режиме round-robin.

Кейс номер 3. IaaS и кластеры

Описанный выше пример отлично работает, но в силу централизованной архитектуры Docker и, как следствие, самого Skydock, работает он только на одной физической (как вариант — виртуальной) машине. Чтобы решить эту проблему, нужна некая облачная платформа, которая позволит запускать контейнеры на кластере машин, выполнять их оркестрацию и балансировку нагрузки. На данный момент существует три ключевых проекта, позволяющих связать Docker и кластеры: OpenStack, CoreOS и Kubernetes (плюс фирменные инструменты от разработчиков Docker, но они до сих пор в стадии альфа/бета).

OpenStack

Поддержка Docker в OpenStack есть в трех формах:

  • драйвер гипервизора в Nova;
  • плагин и шаблон для системы оркестрации Heat;
  • движок в каталоге приложений для Murano.

Поддержка драйвера гипервизора Nova, позволяющего запустить OpenStack поверх Docker вместо классических технологий виртуализации (KVM, vSphere и так далее), появилась в релизе Havana. Сам драйвер достаточно прост в установке и настройке и хорошо интегрируется с Glance (сервис, отвечающий за хранение образов) и Neutron (NaaS). Все, что нужно сделать, — это установить драйвер с помощью pip и внести небольшие изменения в файлы конфигурации Nova и Glance. Весь процесс описан на официальной wiki-странице.

Фреймворк оркестрации OpenStack Heat поддерживает Docker, начиная с релиза IceHouse. Его задача — управление Docker, запущенным поверх виртуальной или реальной машины. С помощью одного конфигурационного файла он позволяет запустить одну или несколько машин, установить в них Docker, а затем запустить контейнеры с нужными сервисами внутри. Пример файла конфигурации для автоматического запуска виртуальной машины, установки в нее Docker и запуска контейнера cirros:

Murano, выполняющий роль каталога приложений в OpenStack, поддерживает Docker с января 2014 года. Он позволяет публиковать, искать и разворачивать Docker-контейнеры с приложениями так же просто, как и обычные приложения. Благодаря этой функциональности можно запустить набор сервисов внутри Docker-контейнеров с помощью нескольких кликов мышью прямо из графического интерфейса.

Драйвер Docker для Nova и его связь с остальными компонентами OpenStack

Принцип работы плагина Docker для Heat

CoreOS

CoreOS — еще один крупный проект, имеющий прямое отношение к Docker. Это минималистичный Linux-дистрибутив, предназначенный для запуска контейнеров в больших кластерах и уже поддерживаемый Amazon, Azure, DigitalOcean, Google и Rackspace в публичных облаках. В рамках проекта также развивается система etcd, представляющая собой распределенное хранилище ключ — значение, предназначенное для управления конфигурацией кластера и service discovery, а с недавнего времени и альтернативная система управления контейнерами Rocket.


Главная задача etcd — распределенное хранение информации о местонахождении каждого компонента кластера, а именно информации о контейнерах, такой как IP-адреса, открытые порты и другое. Демон etcd запускается на каждом CoreOS-хосте и поддерживает консистентное состояние между всеми нодами кластерами с возможностью автоматического выбора новой мастер-ноды etcd в случае выхода текущей из строя. Фактически etcd решает обозначенную выше проблему связи между контейнерами, запущенными на разных машинах.

Rocket

В 2014 году в рамках проекта CoreOS началась разработка новой системы контейнерной виртуализации Rocket, которая должна прийти на смену Docker. Двумя основными поводами для «изобретения велосипеда» стали:

  1. Безопасность и децентрализация. Среди задач Rocket — решить одну из фундаментальных проблем Docker, проблему централизации (на каждой машине свой никак не связанный с другими демон docker). Rocket должен быть таким же простым, как Docker, но с акцентом на децентрализацию и безопасность.
  2. Открытый формат контейнеров. Docker — это ориентированная на приложения платформа, и поддержка консистентного стандартизованного формата контейнеров не входит в задачи его разработчиков. В противовес разработчики Rocket предлагают собственный расширяемый формат AppContainer, который должен стать неким стандартом в области контейнеров.

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

Kubernetes

Свою руку к Docker приложила и Google, запустив проект Kubernetes. Компания открыла его код в июне 2014 года, и уже совсем скоро благодаря усилиям Mirantis он появится в каталоге приложений OpenStack.

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

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

Кейс номер 4. Запускаем софт в песочнице

Docker — превосходный инструмент для запуска приложений в песочнице. В предыдущей статье мы кратко рассмотрели несколько способов запуска консольных и десктопных приложений с помощью Docker, в том числе Firefox с пробрасыванием иксов внутрь контейнера. Сделать это было действительно очень просто, однако мы заимели ряд проблем, одна из которых связана с безопасностью (контейнер получал полный доступ к иксам), а вторая — с тем, что мы пробросили графику, но не пробросили звук. Что ж, пришло время разобраться с этими проблемами.

Есть два способа сделать то, что нам нужно. Первый — это использовать связку из виртуального X-сервера Xephyr и проброса аудиоустройств в контейнер. Второй — использовать функцию форвардинга протокола X11 в SSH и сервер PulseAudio для передачи звука по сети. Первый способ более прост в настройке, но требует, чтобы графическое приложение в контейнере работало внутри окна фиксированного размера (Xephyr — это X-сервер внутри X-сервера), поэтому мы пойдем по второму пути.

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

/tmp (на самом деле имя может быть любым) и копируем в него наш публичный SSH-ключ:

Далее здесь же создаем файл Dockerfile со следующим содержимым:

И собираем образ на его основе:

Теперь нам необходимо настроить PulseAudio на хост-системе так, чтобы он мог принимать звуковые потоки по сети. Для этого используем приложение paprefs:

Запускаем paprefs, переходим на вкладку Network Server и отмечаем галочками опции Enable network access to local sound devices и Don’t requre authentication. Далее запускаем SSH внутри нашего контейнера с Firefox:

Выясняем его IP-адрес:

И подключаемся по SSH

Мастер Йода рекомендует:  Как правильно организовать IT-конференцию международного уровня

Опция -X здесь отвечает за проброс X11, а -R 4713:localhost:4713 создает обратный туннель между портом 4713 контейнера и тем же портом хост-системы. Это дефолтовый порт PulseAudio, а туннель нужен для того, чтобы Firefox смог получить к нему доступ. Оказавшись в контейнере, набираем следующую команду:

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

Вместо выводов

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

Эдриен Моуэт: Использование Docker

Using Docker

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


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

Аннотация к книге «Использование Docker»

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

Разработка и развёртывание программного обеспечения с помощью контейнеров
Контейнеры Docker предоставляют простые быстрые и надёжные методы разработки, распространения и запуска программного обеспечения, особенно в динамических и распределённых средах. Из этого практического руководства вы узнаете, почему контейнеры так важны, какие преимущества вы получите от применения Docker и как сделать Docker частью процесса разработки.
Книга «Использование Docker» предназначена для разработчиков, инженеров по эксплуатации и системных администраторов, особенно для тех, кто живо интересуется практическим применением технологии DevOps, она предоставит обширный материал: от основ, необходимых для запуска десятка контейнеров, до описания сопровождения крупной системы с множеством хостов в сетевой среде со сложным режимом планирования. Книга последовательно проведёт вас по всем этапам, необходимым для разработки, тестирования и развёртывания любого веб-приложения, использующего Docker.
Основные темы, рассматриваемые в книге:
— начало работы с Docker — создание и развёртывание простого веб-приложения;
— использование методик непрерывного развёртывания для продвижения вашего приложения к активному промышленному использованию несколько раз в день;
— изучение различных возможностей и методик для регистрации в системных журналах и наблюдения за многочисленными контейнерами;
— исследование сетевой среды и сетевых сервисов: как контейнеры находят друг друга и каким образом можно установить соединение между ними;
— распределение и организация кластеров контейнеров с целью балансировки нагрузки, масштабирования, устранения критических сбоев и планирования;
— обеспечение безопасности системы, следуя принципам «глубокой или многоуровневой защиты» и минимальных привилегий;
— применение контейнеров для построения архитектуры микросервисов.
«Использование Docker» — подробное практическое руководство по экосистеме Docker, представляющей собой продвижение заключённых в контейнеры приложений-микросервисов от разработки и тестирования к промышленному производству».
— Эдриен Кокрофт, аспирант-исследователь компании Battery Ventures
«Использование Docker» — глубокий, всеобъемлющий обзор программной среды Docker и экосистемы контейнеров. Практическая направленность книги в сочетании с большим количеством примеров упрощает применение теоретических концепций и методик в реальных проектах.»
— Пини Резник, главный инженер компании Container Solutions

Docker для начинающего разработчика

Docker стремительно ворвался в мир контейнеров и за пару лет из надстройки над LXC развился в систему запуска, окрестрирования, кластеризации, конфигурирования, поставки и создания контейнеров с программным обеспечением. Он так-же имеет простой интерфейс для контроля над ограничением ресурсов. Основой основ для докера служат linux namespaces, которые позволяют изолировать и виртуализировать ресурсы системы, такие как сеть, процессы, точки монтирования и пользователи. В итоге мы можем запустить любой процесс совершенно изолированно, как от самой системы так и от других контейнеров, в своем уникальном программном окружении, со своей сетью, деревом процессов, файловой системой и сетью. Все это дело работает исключительно поверх линукса, docker for windows, docker for osx — это велосипеды с линуксовской виртуалкой. Поэтому некоторые вещи работать там не будут, а некоторые ток с бубном.
Имея опыт работы с джейлами во FreeBSD, zfs-зонами Solaris, openvz и lxc системами линукс можно с уверенностью заявить, что докер вылечил большинство болячек предшественников, и значительную часть головников админов/девопсов о том, как запустить перевел в плоскость, где запустить). Имея докерфайл, дженкинсфайл, вагрантфайл и анзибл с паппетом дев, опс, девопс теперь имеет в наличии everything as a code. Что позволяет ему воспроизвести с нуля весь стек разработки и поставки в любое время в любой среде.

Звучит круто, с чего мне начать?

Процесс установки бессмысленно описывать, так как разработчики докера слова “просто” и “понятно” понимают буквально, что в итоге выливается в хорошие доки и простые шаги установки. Здесь можно найти доки для любой популярной платформы.
Итак, докер у нас есть и введя docker в консоли мы ужасаемся от списка команд вываленных на экран. Стоит отметить, что с версии 1.13 появился раздел Mangement Commands, куда со временем перетекут все команды, а они в свою очередь будут удалены. А пока например команды docker container run и docker run идентичны.
Большинство опенсорсных проектов сейчас имеют докерфайлы и уже готовые докер-имейджи. Разработчику нет необходимости устанавливать на свою машину mysql/postgres/redis/mongo/apache/python/nodejs/php итд — все необходимые версии софта упакованы разрабами в официальне образы. Для примера запустим nginx:

Данная команда скачает latest имейдж с офиц репо nginx на докерхаб, создаст и запустит контейнер с nginx(по сути docker run — это комбинация команд docker pull, docker create, docker start и docker attach). В соседней консоли наберем команду docker ps

Здесь мы видим, что у нас запущен один контейнер с обазом nginx. И по сути от нашей команды docker run больше никакой пользы и нет. Чтобы убить контейнер нужно ввести команду docker kill . Чтобы увидеть помимо запущенных и потушенные контейнеры — можно набрать docker ps -a:

Наигрались и удалили контейнер совсем.
Немного добавим параметров в запуск контейнера:

Из непонятных параметров я думаю тут -d и -p. Первый флаг запускает контейнер в бэкграунде, второй паблишит порт(форвардит порт из системы) в контейнер. Теперь перейдя по адресу http://localhost:8080 мы окажемся на приветственной страничке nginx. В систему можно прокидывать любой произвольный порт, но только на тот, что экспозится в контейнере, -p можно задать несколько раз, можно так-же задать диапазон. Команда ниже покажет stdout и stderr контейнера:

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

Так мы открываем интерактивную псевдо-tty консоль( -ti ) а запускаем там bash. И можем установить необходимый софт, который будет доступен на время жизни контейнера:

Чтобы контейнер с nginx стал еще полезнее, пусть он отдает нашу статику:

Таким образом мы монтируем папку /static/content в контейнер с nginx. Аналогично можно примонтировать в контейнер кастомные конфиги в папку /etc/nginx контейнера. В качестве источника можно указать другой контейнер.
Полный список команд докера и их параметров можно посмотреть тут.

Как я уже писал выше, по дефолту docker качает latest таг имейджа, если необходимо указать конкретную версию, это делается через двоеточие например latest версия nginx на базе alpine-linux будет выглядеть как nginx:alpine. Доступные и поддерживаемые версии лучше всего смотреть на официальных страничках докерхаба и стора.

Увлекательно, но мало!

Попробуем разобрать более сложный вариант — мы разрабатываем тему для wordpress и нам необходимо его быстро развернуть у себя локально. Инсталлить пых как модуль апача или фпм, инсталлить мускуль, это все настраивать, а если несколько тем — носиться с вхостами, отдельными бд итд уныло и утомительно. Поэтому идем на офиц странички wordpress и mysql, изучаем, выбираем версии и вперед.
Работать мы будем из корня проекта, тема наша лежит в папке themes/mytheme.
Запускаем базу данных:

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

По дефолту контейнеры друг друга не видят, здесь мы использовали параметр link, чтобы законнектить контейнер с Вордпрессом к контейнеру с бд. Помимо этого включается докеровский резолвер и ипка контейнера с базой данных будет резолвиться по имени db. Этот хостнейм мы используем в настройке Вордпресса через переменную окружения WORDPRESS_DB_HOST. Перейдя на http://localhost мы закончим установку и можем применить нашу тему.
Как видим, две команды и Вордпресс готов. Однако и это можно улучшить — команда докера написала отличный скрипт, который очень полезен для разворачивания комплексных сервисов на рабочих станциях разработчиков.

После простой инсталляции перейдем сразу к предыдущему примеру и перенесем его в docker-compose.yml. Данный файл описывает наши сервисы и контейнеры, параметры запуска итд. На текущий момент существует уже 3.1 версия формата. каждый ямл файл должен начинаться с версии. По умолчанию docker-compose ищет docker-compose.yml в текущей дире, через параметр -f можно указать любой другой файл или перечислить все файл, если их несколько.

Касательно версий, то если грубо — version: “1” — это простое описание команд запуска докер контейнеров в ямл формате. В version: “2” добавилось понятие сервисов, теперь контейнеры можно скейлить, так-же добавилась секция с описанием вольюмов и сетей и их драйверов. По умолчанию, если сеть не задана, docker-compose при запуске создает новый бридж и коннектит все сервисы к нему, включает резолвер (резовлятся как сервисы, так и отдельные контейнеры). Не нужны линки для взаимосвязи между контейнерами. Version: “3” работает только с docker-engine 1.13+. Данная версия учла кривой опыт doker bundle и реализовала простой и прозрачный деплой в swarm-кластер, в 3.1 запилили поддержку docker secrets. Для сингл хоста за глаза второй версии.
docker-compose.yml:

Данный файл положим в корень проекта(как мы видим docker-compose понимает относительные пути, поэтому мы указали ./themes в описание вольюма с темой). Чтобы запустить наш Вордпресс достаточно набрать команду docker-compose up или docker-compose up -d чтобы запустить в бэкграунде:

Данный файл удобно держать с проектом. Таким образом мы или кто-либо еще всегда смогут поднять проект(в нашем случае проект с темой Вордпресса) на любом компе с докером.
Подчистим за собой:

Напишем более сложный ямл, для Вордпреса docker-compose-staging.yml:

В примере выше мы создали вольюм для базы данных db-mysql и примонтировали его в контейнер с мускулем в /var/lib/myql. Сделали мы это для того, чтобы при пересоздании, рестарте итд — данные сохранялись. Так-же создали две сети: внешняя wp-proxy для соединения сервисов nginx и wordpress и внутреннюю wp-db для коннекта сервиса водпресс с базой данных. Для сервиса Вордпресс помимо темы, мы создали два вольюма, для того чтобы заперсистить плагины и аплоад. Теперь при пересоздании контейнеров бд и Вордпресса все наши данные будут сохранятся, так как мы вынесли их из контейнеров.
В качестве прокси мы заюзали имейдж jwilder/nginx-proxy, который слушает сокет докера, и если находит переменную окружения VIRTUAL_HOST — создает указанный виртуалхост у себя в конфигах с проксированием на контейнер, где прописана эта переменная. Если контейнер экспозит несколько портов, надо указать так-же и VIRTUAL_PORT, куда будет проксироваться трафик.

Запустим наше творение:


В /etc/hosts укажем

При переходе в браузере по ссылке http://wp.local откроется привычный визард настроки вордпресса. Внутри контейнера nginx-proxy в конфиг /etc/nginx/conf.d/default автоматом добавится следующая запись:

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

А секция upstream в nginx примет вид:

Помимо этого, в пределах сети wp-proxy оба контейнера доступны по названию сервиса wp. А в версии 3 докер-композа мы можем провернуть тоже самое в swarm-кластере.

В итоге без какого-либо напряга мы создали масштабируемый сервис на Вордпрессе.

Убедил, хочу заиметь свой контейнер!

Для начала сделаем шаг назад — а что такое контейнеры? Обычному человеку при слове контейнер на ум может придти 20и тонник. Это прочный объект, который выдерживает нагрузку во время хранения, погрузки и транспортировки и защищают содержимое, находящееся внутри. В голове так-же может возникнуть картинка с портовым доком, где стоят тысячи контейнеров в рядах, составленные друг на друга. Большая часть мерчанта поставляется в таких контейнерах: они прочны, стандартны, их легко хранить и транспортировать. Основная часть людей, задействованная в поставке не имеет представления что находится внутри, для поставки это не имеет значения. Идея софтварных контейнеров аналогична — это неизменные изолированные образы с ПО, функционал которых доступен чаще всего через вызовы api. Это современное решение для надежного запуска ПО (почти) в любом окружении, будь то комп разработчика, тестовые сервера или продакшн кластер. Не важно где — результат запуска всегда будет неизменным.
Поскольку поведение предсказуемо и неизменно независимо от среды, то самый упоротый диалог на свете наконец уходит в небытие:

QA: не работает n’ный функционал на проде.
Dev: но у меня на компе все ок!

В терминологии докер: контейнер — это запущенный образ. Что из себя представляет изнутри сам образ, советую прочитать эту статью. Если грубо, то докеровский имейдж — это стопка более мелких имеджей, каждый из которых содержит файлы, команды, результат их выполнения и другую мета-инфу. Потом драйвер overlay при запуске все это собирает в заданном порядке и из контейнера это выглядит как цельная единая система. Помимо этого, при старте контейнера поверх всего создается новый слой/имейдж. При удалении контейнера по сути только этот слой и удаляется со всеми изменениями произошедшими во время жизни контейнера, однако их можно “закоммитить” создав новый образ.
Текстовым представлением докеровского образа является Dockerfile. При команде docker build этот файл считывается, каждая строка-команда запускает новый контейнер, а ее результат коммитится в новый слой/имейдж. Далее рассмотрим простой пример и все станет понятно. Для этого склонируем проект:

Мастер Йода рекомендует:  Skype — всё по этой теме для программистов

Проект не мой, я просто его форкнул, немного подправил и добавил Dockerfile:

Каждый Dockefile начинается с команды FROM, так мы объявляем, какой базовый имейдж мы будем использовать. Далее может быть указан MAINTAINER, это просто служебная инфа о том, кто во этом всем виноват. В моем случае за базовый имейдж я взял python:2.7-alpine. после чего идут команды RUN. По сути это инструкция, что нужно выполнить внутри имейджа и закоммитить в новый слой. Если с первой командой все более-менее понятно, то второй RUN выглядит мягко говоря по уродски, ее можно было бы переписать так:

Однако, необходимо помнить, что каждое успешное завершение команды ведет к созданию нового слоя, который записывается поверх предыдущих. Соответственно мы установили пачку пакетов, в тмп склонировали проект, а после установки почистили /tmp и удалили ненужные пакеты. Последние два слоя пометят файлы как удаленные, но сами слои не удалят, а запишутся поверх. В итоге у нас и место не очистится, и файлов в контейнере не будет. Собрав первый Dockerfile мы получим имейдж размером 94Mb, собрав второй, работающий точно так-же — 261Mb. Соответственно при написании докерфайлов всегда следует держать баланс между читаемостью и экономией места, особенно для прода, и по возможности объединять в oneliners команды инсталляции, деинсталляции и удаления, чтобы все это выполнялось в рамках одного слоя.

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

Как уже писал выше, за основу моего имейджа был взят python:2.7-alpine. Это официальный имейдж питона версии 2.7 на базе легковесного дистрибутива linux alpine. В качестве сборки мелких имеджей alpine — лучший выбор, однако следует помнить, что за основу здесь взята сишная либа musl и пока не каждый софт скомпиллится и заработает в alpine.

На проде мы используем debian, как базовый образ, несмотря на то, что весит он больше 120Mb против 4Mb у alpine. Это не проблема, т.к. этот слой копируется только один раз, а все остальные имейджи будут использовать локальную копию. Помимо этого, дебиан надежен и предсказуем, и по умолчанию в нем есть все необходимое.

Но для мелких тулз alpine подходит лучше всего. Самый первый исходный образ — scratch. По сути не содержит ничего. Его можно использовать для гошных бинарников. однако следует не забывать, что необходимо скопировать туда корневые ссл сертификаты и необходимые либы, которые покажет ldd. Советую почитать так-же, что пишут сами докеровцы о докерфайлах. Так-же отличным примером различных техник служат официальные докерфайлы Вордпресс, мускуль, пхп, го, питон, редис итд.

Чтобы собрать наш имейдж необходимо в директории проекта выполнить команду

В качестве имени имейджа мы указали bamboo-build-tools (можно указать несколько), а в качестве контекста для команд COPY и ADD точкой текущую диру. По умолчанию docker build ищет Dockerfile, однако через -f можно указать любой другой файл, аналогично и с контекстом — можно указать любой другой путь.

Еще один головняк для девелопера?

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

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

12 друзей Docker-а – опенсорсные инструменты в помощь разработке

Обучающие книги по программированию.

Обсуждаем книги, предлагаем свой контент, связываемся с админами: @techskillsdiscuss

About
Platform


Unity и C#. Геймдев от идеи до реализации. 2-е изд.

Авторы: Джереми Гибсон Бонд
Год издания: 2020

​Всем привет! Сегодня наша подборка статей посвящена такой популярной среди разработчиков платформе как Docker. Давайте разбираться, что это такое, как работает и какие инструменты пригодятся в работе с этой платформой.

Java в облаке. Spring Boot, Spring Cloud, Cloud Foundry

Авторы: Д. Лонг, К. Бастани
Год издания — 2020

​Всем привет! Сегодня мы собрали для вас статьи на тему выступлений на конференциях (и вообще о публичных выступлениях на технические темы).

Собираетесь выступить с речью на техническую тему? Вам пригодятся эти советы!
https://techrocks.ru/2020/06/01/tips-for-technical-talks/

C# 7 и .NET Core. Кросс-платформенная разработка для профессионалов

Автор: Прайс М.Дж.

Год издания: 2020

​Привет, друзья! Наша сегодняшняя подборка посвящена поиску работы в самых разнообразных проявлениях этого процесса.

«Часто на удалёнке платят больше». Где и как программисту искать удалённую работу
https://techrocks.ru/2020/03/11/work-remotely-earn-more/

Agile: оценка и планирование проектов

Год издания: 2020

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

Самоучитель PHP 7

Авторы: Максим Кузнецов, Игорь Симдянов
Год издания — 2020

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

Секреты JavaScript ниндзя

Авторы: Джон Резиг, Беэр Бибо, Иосип Марас
Год издания — 2020

​Привет, друзья! Сегодня мы собрали для вас статьи о работе за границей. Как живется айтишникам в Берлине, Лондоне и Шанхае? Читайте в наших статьях!

«Получаешь по Blue Card как минимум 42 тысячи евро в год». Тестировщик-сеньор из Бреста о переезде в Берлин и возможностях
https://techrocks.ru/2020/04/26/relocate-in-berlin/

«Сначала положено 5 дней отпуска, с ростом стажа добавляют по одному дню». Белоруска работает в «Яндексе» в Шанхае. Китайцы зовут её Бай Ян — Белый тополь
https://techrocks.ru/2020/04/23/work-in-yandex-in-shanghai/

Bootstrap в примерах

Автор: Сильвио Морето

Год издания: 2020

​Привет, друзья! Сегодня наша подборка посвящена так называемым soft skills — чертам характера и навыкам, не связанным напрямую с вашей профессиональной деятельностью, но очень сильно влияющим на ее успешность.

Язык программирования С++. Cтандарт C++11. Краткий курс



Автор: Бьёрн Страуструп
Год издания: 2020

​Всем привет! Наша сегодняшняя подборка статей посвящена изучению программирования и — отдельно — роли высшего образования в этом деле.

12 друзей Docker-а – опенсорсные инструменты в помощь разработке

Docker, docker, docker. Было время, когда это слово звучало в каждой курилке разработчиков. Хайп вокруг докера уже подугас, однако он по-прежнему может быть полезен как для локальной среды, так и как production-ready решение. Но в посте речь пойдет именно о среде для локальной разработки.

Но для тех, кто не в курсе, на всякий случай:

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами. Изначально использовал возможности LXC, с 2015 года применял собственную библиотеку, абстрагирующую виртуализационные возможности ядра Linux — libcontainer. С появлением ​Open Container Initiative начался переход от монолитной к модульной архитектуре.

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

Что будет уметь наша сборка?

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

  • Собственно сам PHP, последний стабильный релиз 7.1;
  • Composer
  • Mysql, последняя стабильная версия 8;
  • Nginx

Также наша конфигурация будет поддерживать сколько угодно хостов nginx (см. проектов). Добавление новых компонентов в стек обычно не составляет труда, если это не заморская диковина конечно, но об этом позже.

Установка docker

Заострять внимание на процессе установки docker’а нет никакого смысла, на официальном сайте есть подробные мануалы по установке для всех популярных ОС:

Нам еще понадобится docker-compose . Как установить можно прочитать по ссылке.

Файловая структура

Переходим к организации папок и файлов нашей сборки. Создадим на диске какую-нибудь директорию, которая будет корневой для нашей сборки и в ней по порядку создаем следующие директории:

  • www — в этой папке будут лежать файлы наших проектов, по директории на каждый проект;
  • mysql — в этой папке будут храниться файлы наших баз данных;
  • logs — здесь будет собриать логи из разных образов;
  • hosts — здесь будут храниться файлы конфигурации nginx для наших проектов;
  • images — папка с нашими образами — компонентами нашей системы.

Еще не помешает создать дефолтный проект, чтобы проверить работоспособность нашей сборки когда все запустится. В директории www создадим директорию тестового проекта — hello.dev с одим единственным файлом index.php . Содердимое файла index.php классическое:

Также в корне будет лежать наш docker-compose.yml — сердце любой docker-конфигурации 🙂

Собираем образ PHP

Стандартный официальный образ PHP не включает в себя никаких модулей, поэтому чтобы включить их нужно собрать свой образ на основе официального. Звучит немного страшновато, но на деле все просто. Создаем директорию для нашего образа images/php и в ней создаем файл Dockerfile следующего содержания:

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

Docker Compose

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

Структура docker-compose.yml файла предельно простая, если будут вопросы — задавайте в комментариях.

Конфигурация nginx для проектов

Раньше мы уже создали тестовый проект hello.dev , давайте добавим для него конфиг nginx. В папке hosts создадим файл с названием hello-dev.conf :

Конфиг nginx для докер-контейнера ничем не отличается от обычного конфига для сайта. Стоит лишь обратить внимание на директиву fastcgi_pass , где мы используем не путь к unix-сокету, а адрес php:9000 . Здесь присутствует немного магии docker’а: php — это хост по которому доступен наш php контейнер внутри контейнера nginx , ну а 9000 — порт, по которому можно достучаться до fpm-сокета.

Run the magic!

Мы набросали минимальную конфигурацию для локальной среды разработки и можем ее смело запускать. Для этого из корня нашей сборки, где лежит docker-compose.yml файл нужно выполнить команду docker-compose up -d и немного подождать. Первый запуск будет дольше, потому что docker’у нужно скачать образы и собрать образ для php.

В конце концов мы увидим заветные строчки:

Они говорят нам что наши три контейнера запущены и готовы к работе. Проверимс. Для этого откроем браузер и перейдем по адресу http://hello.dev/ , но сперва добавим одну строку в hosts файл.

Важно для windows и mac адрес 127.0.0.1 нужно заменить на адрес виртуальной машины, в которой запускается докер, потому что нативной поддержки пока нет или она очень унылая.

Итак, окрываем браузер и видим:

Наша среда готова для работы. Можно легко добавлять новые проекты — просто создаем новую папку для проекта в www и добавляем новый конфиг для nginx, перезаускаем контейнеры и вперед! Удачи в разработке и пишите вопросы в комментариях.

Знакомимся с основными возможностями Docker

Docker — это действительно Must Have инструмент для разработчика и администратора любого крупного проекта. И даже если это не так, Docker всё равно необходимо знать. Ведь уже в ближайшем будущем он будет везде, начиная от десктопного Linux-дистрибутива и заканчивaя пулом серверов на AWS. А разобраться с ним довольно лeгко, если, конечно, правильно понимать принцип его работы.

На мастер-классе обсудим:

Что такое Docker;

Преимущества перед LXC и классической виртуализацией;

Добавить комментарий