Комментарии 24
Никак не пойму зачем образ операционки в каждом имадже?
Этим достигается атомарность контейнера.
Он и так атомарен, если просто положить в него необходимые сошники.
Ну рокетсайнс здесь нету. Бинарный исполняемый файл может быть двух видов: статически слинкованым или динамически. В случае статики никакие дополнительные библиотеки ему не нужны. И тогда докер файл может быть таким https://github.com/tianon/dockerfiles/tree/master/true В случае динамики — необходимо покопаться.
Вот так выглядят зависимости bash:
$ ldd /bin/bash
linux-vdso.so.1 => (0x00007ffc731ea000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f3b391fa000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3b38ff6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3b38c2c000)
/lib64/ld-linux-x86-64.so.2 (0x0000559c9ee28000)Если вам нужен баш в докере, то в общем-то достаточно найти и положить эти сошники в образ, проверив, что у них самих нет зависимостей. Можно пойти более корректным, но сложным путем, собирая через configure&&make&&make install нужные зависимости. Это длиннее, но если есть CI решаемо. И главное повторяемо, поскольку инструкции у вас зашиты в CI. Тогда можно взять Alpine для базы.
Разумеется это сложно делать для большого, стороннего проекта. Например Nginx или Python. Но это отлично работает для всего, что написано на golang, поскольку у него в зависимостях часто вообще ничего нет. А собрав однажды базовый образ для php/python/ruby/java вы можете без проблем запаковывать ваше приложение, написанное на этих язык. Обновление этого образа будет уже не таким сложным.
Хотя бы чтобы уменьшить количество случаев "а локально у меня работает", если у большинства разработчиков стоит Ubuntu.
Даже в опросах на Хабре он ещё не победил, а только начинает проникновение со скрипом.
Я уже сам столкнулся с тем, что для php есть ppa под ubuntu для расширений, а для центоси альтернатива — сборка из исходников. Что-то мне кажется, для alpine тоже не будет готового пакета, хорошо если сам php из исходников собирать не потребуется.
Ну как сказать. Что у Docker есть проблемы со сборкой контейнеров (только навскидку: передача секретов, монтирование файлов с хоста в целях, например, кэширования, использования билд-онли софта) — не секрет. Стандартными средствами Dockerfile эти проблемы не решаются или решаются довольно коряво. Можно решить их, написав кастомную обвязку на любом языке для конкретных кейсов, можно что-то универсальное, можно пропатчить сам сборщик докера, можно ждать пока кто-то не сделает что-то из этого.
Я на боевых серверах сейчас использую Alpine образы, к примеру архив PHP-FPM образа примерно 80Мb. Он же и выкатывается при релизе, никаких репозиториев.
Бинарные зависимости собираются из временного контейнера и потом экспортируются. Нужно это опять таки чтобы уменьшить размер образа.
Все верно, то что происходит в 1% случаев можно сделать руками, без Chef огородов.
А то получается, что делаем «hello world», берём для этого инструмент энтерпрайз уровня и потом волосы <вставить_что_они_делают_при_упоминании_шефа>
Но ближе к существу, мне действительно интересно, что не так с шефом, когда с ним начинаешь знакомиться. Что лично вам не понравилось?
P.S. по поводу Chef — мне тоже не нравится, я вот например Ansible люблю. Душу как то он сразу согрел, так и не могу от него отказаться. Хотя пробовал Chef/Puppet/SaltStack/Ansible.
У нас в планах поддержка Ansible, будем пробовать успеть до июля.
от нового вашего тех.евангелиста)
М? О чем речь?
Я про это. Слишком тонко я просто написал
Собираем Docker-образы для CI/CD быстро и удобно вместе с dapp (обзор и видео)