blog [dot] hook

Данный пост является переводом части документации, посвященной секции deploy в docker-compose deploy Начиная с версии 3. Группа настроек, посвященная деплою и запуску сервисов. Указанные в данной группе настройки используются только при деплое на swarm используя docker stack deploy, и игнорируется при использовании команд docker-compose up и docker-compose run. version: '3' services: redis: image: redis:alpine deploy: replicas: 6 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure

Данная статья является копией публикации на хабре В данной статье я расскажу о своём опыте “заворачивания” Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов. “А в чём, собственно, сложность?” - можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории: “Использую докер для локальной разработки. Ставлю laradock и беды не знаю”. Круто, но как обстоят дела с автоматизацией и запуском на production? “Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри”. Тоже отлично, прост в запуске, но как на счёт идеологии “один контейнер - один процесс”? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа? “Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь”. Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться? Всё, что ты прочитаешь ниже - является субъективным опытом, который не претендует быть истиной в последней инстанции. Если у тебя будут дополнения или указания на неточности - welcome to comments. Для нетерпеливых - ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно “слинковав” контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

На днях появилась необходимость несколько автоматизировать сборку Docker-образов, и решать эту задачу “привычними” bash-скриптами очень не хотелось. Вспомнил про существование такого зверя как make и, черт подери - это великая тулза, которая уже считай что почти забыта. В процессе работы был найден перевод документации, и дабы он “не потерялся” - разместил его здесь. Программа управления компиляцией GNU make Версия 3.79, апрель 2000 Richard M. Stallman и Roland McGrath, перевод © Владимир Игнатов, 2000. Версия перевода 0.1 Английский оригинал этого текста находится здесь. Оригинал перевода был мною взят с этой страницы.

Столкнулся с ситуацией, когда необходимо переопределить расположение .env файла, который используется, к примеру - для запуска phpunit тестов. Да, если в корне приложения имеется файл .env.testing - то он автоматически будет прочитан фреймворком при APP_ENV равным testing, но вот что делать, если этот файл необходимо разметить в какой-либо другой директории? Давай расположим его в ./env.d/ дабы, например, не “мусорить” в корне приложения.

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

Частенько при разработке приложения с использованием requirejs возникает необходимость в реализации паттерна синглтона. И вот, испробовав пример его реализации что описан ниже заявляю - он имеет право на жизнь. Не без своих недостатков, разумеется, но в целом вполне применибельно:

Данный пост - предостережение тем, кто решил приобрести у них какие-либо услуги, и услуги VPS - в частности. Тем, кто перед оплатой решил поискать о них отзывы. Ниже будет аргументированное мнение, почему они являются куском говна: Нет информации про юрлицо, лицензии и т.д.; Покупают положительные отзывы. Мне предлагали зачисление на мой баланс месячной стоимости аренды VPS сервера за позитивный пост об их услугах в блоге или соц. сетях. Это сразу насторожило, но сперва не придал этому значения.