blog [dot] hook

Как пользователь электро-самоката M365 версии Pro со стажем — могу смело заявить, что быть заметным как для участников дорожного движения, так и пешеходного — очень важно. Если передвигаясь днём по обочине дорог и/или тротуару можно считать что твоя заметность достаточна для других участников движения (недостаток с лихвой компенсируется светоотражающим жилетом), то вот в темное время суток картина сильно меняется. Особенно это чувствуется при движении по тротуару со включенной фарой - особенность устройства и расположения фары на самокате таковы, что идущих тебе на встречу ты просто слепишь, а сзади тебя не видно от слова совсем. Задавшись вопросом “как это можно исправить” было принято решение интегрировать пару led-лент в днище самоката так, что бы они освещали землю под ним (тем самым обозначая твоё местоположение для других) и чтоб при этом надежность примененного решения не вызывала сомнения. Ниже будет в меру подробное описание того, как подсветка была имплементирована, какие комплектующие для этого были выбраны, их цены и с какими сложностями столкнулся.

Однажды я решил поднять свой крохотный кластер для приложений, запускаемых в docker-контейнерах. Выбор был между nomad (уже не один комрад его настоятельно рекомендовал - обязательно попробую, но позже), K8S (слишком сложно и дорого по ресурсам для pet-проекта) и Docker Swarm (никакого дополнительного софта не потребуется, поставляется вместе с самим докером). Как ты понимаешь - выбор пал именно на последний. По тому как его поднять и базово настроить - материалов полно, но когда дело дошло до настройки огненной стены - вот тут начались некоторые трудности.

Так уж получается, что репозитории с пакетами частенько отстают в версиях ПО, которое предоставляют. Частный случай - нужно подключиться к удаленной системе используя не “традиционный” туннель, а ssh jump. На борту Linux Mint 18.3 стоит openssh, который ещё не поддерживает эту фичу:

Хочу рассказать про мужика-медоеда. Этот отморозок вызывает во мне искреннее восхищение. Жил-был Адриан Картон ди Виарт. Родился он в 1880 году в Бельгии, в аристократической семье. Чуть ли не с самого рождения он проявил хуевый характер: был вспыльчивым до бешенства, несдержанным, и все споры предпочитал разрешать, уебав противника без предупреждения. Когда Адриану исполнилось 17 лет, аристократический папа спихнул его в Оксфорд, и вздохнул с облегчением. Но в университете блистательный отпрыск не успевал по всем предметам. Кроме спорта. Там он был первым. Ну и еще бухать умел. — Хуйня какая-то эти ваши науки, — решил Адриан. — Вам не сделать из меня офисного хомячка.

Данный пост является переводом части документации, посвященной секции 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 Английский оригинал этого текста находится здесь. Оригинал перевода был мною взят с этой страницы.