Ссылка на презентацию: drive.google.com/file/d/1SnTN_pow1BK225FC1_UL7nMj0FrGQw6T/view?usp=share_link
@ivanspitsyn8951
Жыл бұрын
Привет, какой раз пересматриваю твой доклад с подлодки, одним словом восторг! Подскажи вышел ли у тебя курс по докеру?
@alexndrnovikov
Жыл бұрын
@@ivanspitsyn8951 привет. честно говоря, такого запроса особо не было, как и времени на его написание) может однажды дойдут руки, но пока что его нет. Да и новая информация копится чуть медленнее по теме, чем хотелось бы, вот до перевода сборки на Podman руки никак не дойдут, а там кэширование промежуточных слоев выглядит весьма перспективно
@XAKEPEHOK
Жыл бұрын
Охренеть, мужик, это очень крутое видео, спасибо огромное! Мне так этого всего не хватало!
@den-rad
Жыл бұрын
Спасибо, очень полезные ссылки.
@antonbaton1120
Жыл бұрын
Годнота! Спасибище!
@mnogokotin
Жыл бұрын
спасибо за видео оч полезно
@innerfly5648
Жыл бұрын
Очень полезно, спасибо!
@antonsamofal7655
Жыл бұрын
@alexndrnovikov Спасибо за доклад, вроде не новичок в Docker, но все равно нашел для себя много полезного. Я протестировал docker-php-extension-installer. Вполне простенький список расширение: mysqli, pdo_mysql, opcache, gd, bcmath, exif, zip, pcntl, imagick-3.7.0, xdebug-3.2.0 По итогу apt-get (несколько зависимостей) + docker-php-ext-isntall (дефолтный скрипт из php образа) + pecl ставят расширения примерно за 150с. А этот docker-php-extension-installer - за 290-300с. Рзаница почти в 2 раза. Оно конечно удобней с помощью этого скрипта ставить, но похоже они там все расширения из сорсов билдят (наверерное), ибо на столько дольше выходит...
@alexndrnovikov
Жыл бұрын
а размер финального образа отличается? мне почему-то кажется, что с docker-php-extension-installer он еще и больше должен получаться, но я пока не замерял
@antonsamofal7655
Жыл бұрын
@@alexndrnovikov Я бегло глянул, у меня размер вышел идентичный в мегабайтах, что подозрительно... поэтому я допускаю, что это я невнимательно посмотрел просто... нужно более чистый тест провести.
@antonsamofal7655
Жыл бұрын
@Виктор Таиров Ну пока я решил все же оставить использования этого скрипта. С ним Dockerfile выглядит заметно чище и меньше беспокойств в духе "а не забыл ли я какую зависимость к екстеншену еще поставить". В общем, поживу пока с ним, а там видно будет... Можно и самому руками собирать расширения, но зачем?
@forest_grow
8 ай бұрын
Не раскрыта проблема, когда необходимо изменять сам код. Cобирать (build) проект заново каждый раз? А если использовать тома (volumes), то как это правильно делать (с учетом того, что нам необходимо, чтобы сначала выполнилась команда composer install, а затем запустился, к примеру, RoadRunner)?
@alexndrnovikov
7 ай бұрын
На CI для тестовых и прод окружений - точно проще каждый раз собирать, с кэшем образов это все равно быстро, даже если в composer.lock что-то и меняется. Локально вариантов больше, но тоже решаемо - если не Roadrunner - то простого volume в хост систему будет достаточно, поменяли в IDE - приложение подтянуло - в случае с Roadrunner - есть конфиги для локальной разработки (раньше с 1 воркером выполняющим 1 задачу максимум и умирающим, в более свежей версии - есть специальный дебаг режим делающий почти то же самое, но воркеров больше). Это решает проблему "изменился код - rr обновил воркеры". Тут локально нужно просто cmd контейнера менять на такой, который запускает rr с этим конфиг файлом. Либо в volume перетереть дефолтный этим, строкой вида - .rr.dev.yml:/var/www/.rr.yml С композером сложнее. Тут я вижу 2 варианта: либо в cmd образа ставить .sh скрпит, в котором сначала выполняется composer i (ну и если надо какие-то миграции другие команды) и потом запускается rr - это способ обновить зависимости до запуска приложения. Этот вариант довольно удобный. С ним docker restart контейнера с приложением решит проблему и починит/обновит все что надо, и так как зависимости обычно нечасто меняются - это нормальный вариант. Другой случай - когда собрка образов с обновленными зависимостями выполняется автоматически на CI, и тогда локально мы подтягиваем только свежий образ, и в volume тогда прокидываем только файлы приложения, без папки vendor. Ну и вишенка на торте - эти сценарии можно упросить и автоматизировать с помощью новой фичи docker compose watch , но я на практике еще до этого не добрался, так что без примеров :)
@Списокпокупок
Жыл бұрын
25:21 на какой секунде объясняется naxya это нужно?
@alexndrnovikov
Жыл бұрын
Условно где-то тут kzitem.info/news/bejne/l5Ctsp1pr32Tlqw , но вообще я это на Podlodka PHP Crew на лайвкодинге чуть подробнее рассказал. Пример - если в команде кто-то работает на парочке проектов одновременно (а например это часто может быть в проекте с микросервисами, или в аутсорсе) - то есть неплохой шанс, что порт на хосте какой-то уже занят, т.е один и тот же указан в 2х разных проектах в docker-compose.yaml. Условно, в одном проекте nginx 80:80 и на другом тоже. Придется где-то менять например на 81:80. А после изменений оказывается, что у другого человека в команде уже есть другой проект с 81 портом, и после пулла ветки отвалится уже у него. Если же вместо хардкода использовать плейсхолдер указанный - то каждый может спокойно менять локальный порт в .env, который в .gitignore, так что вдруг у кого-то законфликтовал порт - он его меняет для себя локально, и не затрагивает команду постоянными изменениями общего файла
@backendforever
Жыл бұрын
Это ж как нужно ненавидеть клавиатуру, чтобы уже к 27-й минуте по ней бить так сильно?! От это звук громче, чем голос автора видео.
@alexndrnovikov
Жыл бұрын
сорри, комбо "новый чувствительный микрофон" + "механическая клавиатура" , использованное в первой раз, дало такой эффект. Я её на самом деле очень нежно нажимал, почти что гладил)
@fitter2boss72
Жыл бұрын
То что не рассказаи, может в следующий раз? :)
@fitter2boss72
Жыл бұрын
Прям хорошая презентация, но звук ... , то ли верние срезали, то ли еще что-то , прям заставляет напрягаться, что бы слышать, а не слушать. Всеравно, спасибо.
Пікірлер: 20