Я когда-то делал себе "иконку в трее" чтобы управлять vpn-клиентом, у которого есть только cli интерфейс. Кто-то из коллег тогда сказал что вроде как есть уже готовая программа, которая висит в трее и показывает меню, которое задаётся через конфиг. Увы, не помню название.
А этот свой лаунчер я сразу же забросил, т.к. оказалось удобнее просто сделать себе алиасы в баше, а постоянно видеть статус подключения не так уж и важно.
Есть вариант попроще - вывести текущий воркспейс в bash prompt.
Ну или сделать интерфейс управления в виде веб-приложения, которое показывает какое окружение запущено, позволяет запустит/остановить, и может даже показывает адреса компонентов, получая их из docker inspect (container name + container ip + exposed port) или же из лейблов контейнеров если они заданы
Это не связанные вещи. Утечка данных - это проблема защиты магазина, а не следствие того что магазин собирает эти данные.
Это примерно как винить человека придумавшего автомобиль во всех авариях. Авария - следствие несоблюдения ПДД. Утечка данных - косяк ИБ в этом магазине. Это никак не отменяет того факта, что на машине передвигаться удобнее чем пешком, и того что удобно делать заказ одной кнопкой, не вводя каждый раз куда и кому привезти заказ.
Нельзя анонимно купить товар с доставкой на дом. Продавцу нужен ваш адрес, номер телефона чтобы связаться в случае проблем, адрес почты чтобы выслать чек.
Да, можно придумать сценарий, когда эта информация удаляется поле обработки заказа. Но вам самому будет не очень удобно вводить всё это каждый раз, если вы постоянно делаете заказы в этом магазине.
1) вам не нужно узнавать адрес kubeapi, когда вы хотите запускать агенты в том же кластере где и развернут дженкинс. Дженкинс умеет читать адрес из стандартной env переменной в поде, достаточно просто ничего не указывать в поле адреса.
2) стоит позаботится о правах сервисакаунта используемого подом дженкинса. Если в кластере включён rbac, то дженкинс не сможет создать под агента.
3) не стоит использовать ip адрес пода дженкинса. У в любом случае должен быть svc для дженкинса, используйте его имя как домен, главное не забыть разрешить в нем порт 50000 для связи с агентом.
4) pod template в конфигурации клауда нужен только для запуска freestyle или неадаптированных пайплайнов. Если пишете пайплайн с нуля, то параметры пода можно указать прямо в пайплайне.
Да, простая идея, что конкретные версии рантаймов и инструментов не должны засорять машину разработчика получает всё больше реализаций.
Аналогичную цель преследуют и laradock и laravel sail.
Однако bash и make недостаточно гибкие, а задачи постепенно становятся всё более сложными. В системах, состоящих из десятков сервисов, одно только клонирование всех их может порядком утомить, не говоря уже об установке зависимостей или ежедневном запуске той или иной группы сервисов.
Позанимавшись некоторое время скриптоводством я перешёл на ELC - обёртку над docker-compose, написанную на golang.
Слишком много аналогий с программированием. Аналогии, так же как и модели, всегда неверны, а точнее лишь частично отражают суть явления. При этом модель специально конструируется, а вот аналогия подбирается. Мало того, что можно подобрать неудачную аналогию, так ещё и функция у аналогии опасная - объяснить явление через уже знакомый пример. Неправильная аналогия формирует неправильное понимание у читателя. Приводя много аналогий с программированием вы, во-первых, рискуете увлечься и придумать лишние, хуже отражающие суть аналогии, а во-вторых, создаёте ещё одну, более абстрактную аналогию, связывающую биологию и программирование.
Если говорить о системе где недопустим даунтайм, то да, схема развёртывания тут неверна.
Но когда видишь в одном месте битрикс и запуск бд и веб-сервера на одной машине, остаётся только порадоваться что тут используется докер и что все компоненты не завернуты в один контейнер.
Легко. Механизмы изоляции процессов, на которых основана контейнеризация, используются даже тогда, когда вы не используете контейнеры. Например systemd использует и cgroups и namespaces. Просто на всякий случай, вдруг вы захотите ими управлять.
Да, создавая новый нейсмпейс вы выделяете в ядре какие-то дополнительные дескрипторы. Это можно посчитать тратой памяти. Потратите несколько килобайт. Думаю это где-то в пределах погрешности, т.к. процессы внутри контейнеров потребляют на два-три порядка больше.
Например за тем чтобы не париться с тем какие версии по есть в репозиториях того дистрибутива, который сейчас на сервере. Обновить версию докеризированной субд становится в разы проще.
По той же причине не страшно переезжать с какого-нибудь умирающего центоса на убунту.
Запуск прод версии сайта в докере полезно тем, что становится очень просто развернуть dev версию контейнера, т.е. вы получаете окружение максимально похожее на боевое.
Плюсов в этом подходе больше чем минусов. Можно порассуждать о том, что для прода можно выбрать что-то посерьёзнее чем docker-compose, но и кубернетис был бы тут вероятно избыточным.
Так или иначе это уже шаг в сторону современной архитектуры и это лучше чем некоторые альтернативы.
Вы приводите решение для простой ситуации, когда значение нового столбца можно рассчитать средствами СУБД. Такое не всегда возможно, да и если логика формирования значения столбца настолько проста и стабильна что мы её помещаем в БД, то потребность в столбце вообще отпадает.
Автор же показывает обобщённое решение, которое подходит в любой ситуации. Да, его можно оптимизировать в частных случаях, но будет неправильно говорить, что раз в частных случаях можно проще, то описанный подход вообще не нужен.
Laradock, мне кажется, наследует идеи таких решений как OpenServer, однако "фича" ларадока относительно опенсервера одновременно и мешает ему быть логичным.
Ценность OpenServer, Xampp, Wamp, Mamp в том, что вам не надо знать как оно работает и не надо ничего настраивать. Вы просто устанавливаете одну программу, и в ней мышкой накликиваете какие компоненты вам нужны. В этом есть ценность, т.к. это сильно проще чем скачивать компоненты по отдельности и править их конфиги. Ценность есть ещё и в том, что эти решения позволяют менять версии ПО. Это было очень важно десять лет назад, когда установка каждого компонента системы была квестом - скачай архив или установщик, он тебе гвоздями к системе прибьётся, потом иди ищи где его конфиги и т.д.
С распространением докера эти проблемы, для тех кто освоил докер и хоть немного научился работать с используемыми компонентами, отошли на второй план. Сейчас очень просто получить работающий nginx, fpm, mysql, etc просто набрав команду в терминале. Добавляем сюда docker-compose и ещё упрощаем себе жизнь - количество вводимых команд стремится к минимуму, а запустив новый проект можно просто скопировав в него пару файлов.
Ларадок по сути является таким хитрым большим docker-compose файлом. Ну да, там есть пара скриптов чтобы настроить какие компоненты использовать, ведь самих компонентов там едва ли не сотня. Но ничего нового по сравнению с самописным файлом ларадок не даёт. Только экономит время на старт, но раз-другой написав свой конфиг, вы в дальнейшем можете его копировать едва ли не быстрее чем стартует ларадок.
Sail в этом отношении делает шаг вперёд. Он не просто является docker-compose файлом. Он даёт разработчику новую возможность - позволяет выполнить команду в контейнере в контексте текущего проекта. Это почти как docker exec, только короче, и не требует указывать имя контейнера. Это важно, ведь разработчику часто приходится вызывать composer и artisan, и выполняться они строго в том же окружении, в котором работает разрабатываемое приложение.
Стоит отметить, что многие вещи в экосистеме laravel делаются в точном соответствии с их слоганом - framework for web artisans. Это не плохо, но иногда приходится объяснять молодым разработчикам, что если что-то заложено во фреймворк, это ещё не значит что это оптимальное решение во всех ситуациях. Некоторые вещи, бесспорно удобные, могут успешно применяться, когда вы делаете бложик или магазин рассчитанный на 100 заказов в год, но при этом они же могут ставить палки в колёса, когда ваш магазин должен обрабатывать тысячи заказов в день.
Подобный подход прослеживается и в Laravel sail. Это решение, которое позволяет организовать разработку одного веб-сервиса, при этом вам всё ещё нужен php определённой версии на хосте.
Есть аналогичный инструмент, который используя тот же принцип действия, решает более существенные проблемы. Например, позволяет не иметь на хосте php вообще. Это важно, когда вы работаете над разными проектами, и у них разные требования к версиям и модулям php. Генерирует git хуки чтобы они выполнялись в контейнере. Позволяет запускать несколько разрабатываемых веб-сервисов и определять зависимости между ними.
Спасибо за пост, всегда интересно как что-то устроено у других.
У вас как-то не показано как перезапускается процесс, который слушает порт 3000
Кроме того деплой через удаление папки и копирование её обратно вызывает перебои в работе сайта.
Я когда-то делал себе "иконку в трее" чтобы управлять vpn-клиентом, у которого есть только cli интерфейс. Кто-то из коллег тогда сказал что вроде как есть уже готовая программа, которая висит в трее и показывает меню, которое задаётся через конфиг. Увы, не помню название.
А этот свой лаунчер я сразу же забросил, т.к. оказалось удобнее просто сделать себе алиасы в баше, а постоянно видеть статус подключения не так уж и важно.
Есть вариант попроще - вывести текущий воркспейс в bash prompt.
Ну или сделать интерфейс управления в виде веб-приложения, которое показывает какое окружение запущено, позволяет запустит/остановить, и может даже показывает адреса компонентов, получая их из docker inspect (container name + container ip + exposed port) или же из лейблов контейнеров если они заданы
Похоже на ELC
А при чём тут next.js и вообще JS?
Все перечисленные уязвимости - это ошибки в коде без привязки к языку и фреймворку.
Это не связанные вещи.
Утечка данных - это проблема защиты магазина, а не следствие того что магазин собирает эти данные.
Это примерно как винить человека придумавшего автомобиль во всех авариях. Авария - следствие несоблюдения ПДД. Утечка данных - косяк ИБ в этом магазине.
Это никак не отменяет того факта, что на машине передвигаться удобнее чем пешком, и того что удобно делать заказ одной кнопкой, не вводя каждый раз куда и кому привезти заказ.
Да, но это всё-равно менее удобно. Если покупатель захочет сделать заказ с телефона или с другого компьютера, то всё придётся вводить заново.
В условиях конкуренции магазины будут делать свои системы более удобными для покупателя.
Нельзя анонимно купить товар с доставкой на дом.
Продавцу нужен ваш адрес, номер телефона чтобы связаться в случае проблем, адрес почты чтобы выслать чек.
Да, можно придумать сценарий, когда эта информация удаляется поле обработки заказа. Но вам самому будет не очень удобно вводить всё это каждый раз, если вы постоянно делаете заказы в этом магазине.
За утверждение про то что 99% рациона человека составляло мясо спасибо. Не знал что мои моляры предназначены для жевания мяса.
1) вам не нужно узнавать адрес kubeapi, когда вы хотите запускать агенты в том же кластере где и развернут дженкинс. Дженкинс умеет читать адрес из стандартной env переменной в поде, достаточно просто ничего не указывать в поле адреса.
2) стоит позаботится о правах сервисакаунта используемого подом дженкинса. Если в кластере включён rbac, то дженкинс не сможет создать под агента.
3) не стоит использовать ip адрес пода дженкинса. У в любом случае должен быть svc для дженкинса, используйте его имя как домен, главное не забыть разрешить в нем порт 50000 для связи с агентом.
4) pod template в конфигурации клауда нужен только для запуска freestyle или неадаптированных пайплайнов. Если пишете пайплайн с нуля, то параметры пода можно указать прямо в пайплайне.
Да, простая идея, что конкретные версии рантаймов и инструментов не должны засорять машину разработчика получает всё больше реализаций.
Аналогичную цель преследуют и laradock и laravel sail.
Однако bash и make недостаточно гибкие, а задачи постепенно становятся всё более сложными. В системах, состоящих из десятков сервисов, одно только клонирование всех их может порядком утомить, не говоря уже об установке зависимостей или ежедневном запуске той или иной группы сервисов.
Позанимавшись некоторое время скриптоводством я перешёл на ELC - обёртку над docker-compose, написанную на golang.
Слишком много аналогий с программированием. Аналогии, так же как и модели, всегда неверны, а точнее лишь частично отражают суть явления. При этом модель специально конструируется, а вот аналогия подбирается. Мало того, что можно подобрать неудачную аналогию, так ещё и функция у аналогии опасная - объяснить явление через уже знакомый пример. Неправильная аналогия формирует неправильное понимание у читателя. Приводя много аналогий с программированием вы, во-первых, рискуете увлечься и придумать лишние, хуже отражающие суть аналогии, а во-вторых, создаёте ещё одну, более абстрактную аналогию, связывающую биологию и программирование.
А в целом материал хороший, мне понравилось.
Автор даёт свою классификацию закладок и способов их появления, и далее оценивает реализуемость и применимость своих же идей.
Если говорить о системе где недопустим даунтайм, то да, схема развёртывания тут неверна.
Но когда видишь в одном месте битрикс и запуск бд и веб-сервера на одной машине, остаётся только порадоваться что тут используется докер и что все компоненты не завернуты в один контейнер.
Легко. Механизмы изоляции процессов, на которых основана контейнеризация, используются даже тогда, когда вы не используете контейнеры. Например systemd использует и cgroups и namespaces. Просто на всякий случай, вдруг вы захотите ими управлять.
Да, создавая новый нейсмпейс вы выделяете в ядре какие-то дополнительные дескрипторы. Это можно посчитать тратой памяти. Потратите несколько килобайт. Думаю это где-то в пределах погрешности, т.к. процессы внутри контейнеров потребляют на два-три порядка больше.
Например за тем чтобы не париться с тем какие версии по есть в репозиториях того дистрибутива, который сейчас на сервере. Обновить версию докеризированной субд становится в разы проще.
По той же причине не страшно переезжать с какого-нибудь умирающего центоса на убунту.
Запуск прод версии сайта в докере полезно тем, что становится очень просто развернуть dev версию контейнера, т.е. вы получаете окружение максимально похожее на боевое.
Плюсов в этом подходе больше чем минусов. Можно порассуждать о том, что для прода можно выбрать что-то посерьёзнее чем docker-compose, но и кубернетис был бы тут вероятно избыточным.
Так или иначе это уже шаг в сторону современной архитектуры и это лучше чем некоторые альтернативы.
Вы приводите решение для простой ситуации, когда значение нового столбца можно рассчитать средствами СУБД. Такое не всегда возможно, да и если логика формирования значения столбца настолько проста и стабильна что мы её помещаем в БД, то потребность в столбце вообще отпадает.
Автор же показывает обобщённое решение, которое подходит в любой ситуации. Да, его можно оптимизировать в частных случаях, но будет неправильно говорить, что раз в частных случаях можно проще, то описанный подход вообще не нужен.
Laradock, мне кажется, наследует идеи таких решений как OpenServer, однако "фича" ларадока относительно опенсервера одновременно и мешает ему быть логичным.
Ценность OpenServer, Xampp, Wamp, Mamp в том, что вам не надо знать как оно работает и не надо ничего настраивать. Вы просто устанавливаете одну программу, и в ней мышкой накликиваете какие компоненты вам нужны. В этом есть ценность, т.к. это сильно проще чем скачивать компоненты по отдельности и править их конфиги. Ценность есть ещё и в том, что эти решения позволяют менять версии ПО. Это было очень важно десять лет назад, когда установка каждого компонента системы была квестом - скачай архив или установщик, он тебе гвоздями к системе прибьётся, потом иди ищи где его конфиги и т.д.
С распространением докера эти проблемы, для тех кто освоил докер и хоть немного научился работать с используемыми компонентами, отошли на второй план.
Сейчас очень просто получить работающий nginx, fpm, mysql, etc просто набрав команду в терминале. Добавляем сюда docker-compose и ещё упрощаем себе жизнь - количество вводимых команд стремится к минимуму, а запустив новый проект можно просто скопировав в него пару файлов.
Ларадок по сути является таким хитрым большим docker-compose файлом. Ну да, там есть пара скриптов чтобы настроить какие компоненты использовать, ведь самих компонентов там едва ли не сотня. Но ничего нового по сравнению с самописным файлом ларадок не даёт. Только экономит время на старт, но раз-другой написав свой конфиг, вы в дальнейшем можете его копировать едва ли не быстрее чем стартует ларадок.
Sail в этом отношении делает шаг вперёд. Он не просто является docker-compose файлом. Он даёт разработчику новую возможность - позволяет выполнить команду в контейнере в контексте текущего проекта. Это почти как docker exec, только короче, и не требует указывать имя контейнера. Это важно, ведь разработчику часто приходится вызывать composer и artisan, и выполняться они строго в том же окружении, в котором работает разрабатываемое приложение.
Стоит отметить, что многие вещи в экосистеме laravel делаются в точном соответствии с их слоганом - framework for web artisans.
Это не плохо, но иногда приходится объяснять молодым разработчикам, что если что-то заложено во фреймворк, это ещё не значит что это оптимальное решение во всех ситуациях.
Некоторые вещи, бесспорно удобные, могут успешно применяться, когда вы делаете бложик или магазин рассчитанный на 100 заказов в год, но при этом они же могут ставить палки в колёса, когда ваш магазин должен обрабатывать тысячи заказов в день.
Подобный подход прослеживается и в Laravel sail. Это решение, которое позволяет организовать разработку одного веб-сервиса, при этом вам всё ещё нужен php определённой версии на хосте.
Есть аналогичный инструмент, который используя тот же принцип действия, решает более существенные проблемы. Например, позволяет не иметь на хосте php вообще. Это важно, когда вы работаете над разными проектами, и у них разные требования к версиям и модулям php. Генерирует git хуки чтобы они выполнялись в контейнере. Позволяет запускать несколько разрабатываемых веб-сервисов и определять зависимости между ними.