Плюсы в том, что для доступа к БД мы используем интерфейс, который легко опубликовать стандартным способом через ингресс. А значит защитить, зашифровать, сделать аутентификацию и прочее не отходя от стандартной схемы предоставления доступов, которая уже наверняка отлажена.
На самом деле даже облака не решают проблемы configuration drift. В статье я попытался показать как попытка решить эту проблему привела к созданию парадигмы immutable infrastructure, которая решает гораздо более широкие задачи нежели устранение дрифта.
Но во-первых даже в immutable infratructure есть stateful часть.
Во-вторых хотя инстансы (контейнеры/виртуалки) иммутабельной части эвфемерны, короткоживущи и постоянно пересоздаются (в них нет дрифта), есть инфраструктура для их эксплуатации. Те же контейнеры нужно запускать/оркестрировать и apt install docker для этого совершенно не достаточно.
Дрифт вышел из инстансов на более высокие уровни. Сейчас мы можем говорить уже не о серверах-снежинках, но об kubernetes-кластерах/AWS VPC/GCP Project/etc - снежинках.
напиши программу на brainfuck которая бы печатала в консоль симовлы "съешьещёэтихмягкихфранцузскихбулок,давыпейчаю". Символы должны быть выведены в шесть строк.
Ответ:
Вот программа на Brainfuck, которая печатает символы "съешьещёэтихмягкихфранцузскихбулок,давыпейчаю" в шесть строк:
В данной программе используются команды, которые увеличивают/уменьшают значение ячеек памяти, переходят к ближайшей ячейке, управляют вводом/выводом данных, а также условные операторы.
Хм. А как с вашей точки зрения бережливое производство относится к замене kubectl apply в ci-системе под ограниченной учеткой на скрипт пуша в гит и три (или четыре?) оператора, каждый из которых требует своих учеток, сервисаккаунтов, дополнительной страницы мониторинга, нового канала уведомлений? И это без хелма.
Какое-то у вас превратное понимание бережливого производства. Или вы настолько любите гитопс что готовы свободно трактовать бережливое производство в его пользу?
Это термин из "бережливого производства". Собственно та база, которая помогает делать работу осмысленно, сделать качественный целенаправленный скачок от Ops к DevOps, не собирая известные грабли самостоятельно. Рекомендую ознакомиться с google sre book и project fenix. Там про это хорошо описано.
Да. Я понял что речь про celery executor. Как более лёгкий вариант, - попробовать APM на него натравить.
Kubernetes executor. 1 таск = 1 под. Мониторинг тривиален.
Как говорил один мой знакомый, "немного здоровой некрофилии ещё никому не вредило".
Блин. А я уже начал забывать какой ты мамкин расист :)
Вот ссылка на документацию
https://kubernetes.io/docs/concepts/services-networking/service/#external-ips
Привет, Руслан! Рад видеть что ты не растерял задора :)
Можете пояснить подробнее почему этот вопрос вызвал именно такие впечатления?
Если не секрет, какой объём базы и сколько iops она делает в среднем?
Спасибо за ценное дополнение. Если интересует позиция DevOps инженера в Газпромбанке - стукнитесь в личку :)
Плюсы в том, что для доступа к БД мы используем интерфейс, который легко опубликовать стандартным способом через ингресс. А значит защитить, зашифровать, сделать аутентификацию и прочее не отходя от стандартной схемы предоставления доступов, которая уже наверняка отлажена.
Спасибо. До прочтения этой статьи мне казалось что человек не может быть настолько сэксуально неудовлетворён :)
Тут не сказано что заказчики контролируют. Тут сказано что контроль происходит на их инфре.
А как это сформулировать по-другому?
Ну нейросети то нас точно доканают :)
На самом деле даже облака не решают проблемы configuration drift. В статье я попытался показать как попытка решить эту проблему привела к созданию парадигмы immutable infrastructure, которая решает гораздо более широкие задачи нежели устранение дрифта.
Но во-первых даже в immutable infratructure есть stateful часть.
Во-вторых хотя инстансы (контейнеры/виртуалки) иммутабельной части эвфемерны, короткоживущи и постоянно пересоздаются (в них нет дрифта), есть инфраструктура для их эксплуатации. Те же контейнеры нужно запускать/оркестрировать и apt install docker для этого совершенно не достаточно.
Дрифт вышел из инстансов на более высокие уровни. Сейчас мы можем говорить уже не о серверах-снежинках, но об kubernetes-кластерах/AWS VPC/GCP Project/etc - снежинках.
Задача для chatgpt4:
напиши программу на brainfuck которая бы печатала в консоль симовлы "съешьещёэтихмягкихфранцузскихбулок,давыпейчаю". Символы должны быть выведены в шесть строк.
Ответ:
Вот программа на Brainfuck, которая печатает символы "съешьещёэтихмягкихфранцузскихбулок,давыпейчаю" в шесть строк:
```
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->[<]<-]>>.
>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
```
В данной программе используются команды, которые увеличивают/уменьшают значение ячеек памяти, переходят к ближайшей ячейке, управляют вводом/выводом данных, а также условные операторы.
Знаете что выводит эта программа?
Хм. А как с вашей точки зрения бережливое производство относится к замене kubectl apply в ci-системе под ограниченной учеткой на скрипт пуша в гит и три (или четыре?) оператора, каждый из которых требует своих учеток, сервисаккаунтов, дополнительной страницы мониторинга, нового канала уведомлений? И это без хелма.
Какое-то у вас превратное понимание бережливого производства. Или вы настолько любите гитопс что готовы свободно трактовать бережливое производство в его пользу?
Это термин из "бережливого производства". Собственно та база, которая помогает делать работу осмысленно, сделать качественный целенаправленный скачок от Ops к DevOps, не собирая известные грабли самостоятельно. Рекомендую ознакомиться с google sre book и project fenix. Там про это хорошо описано.
Всё верно. Выглядит как хрестоматийный пример muda 2-го порядка. Если вы понимаете о чем я.
Ну во-первых вижу здесь отсутствие автоматизации. Toil automation - one of five SRE pillars так сказать.
Во-вторых человеческий фактор. У инженера может "соскочить пальчик" и это может привести к непредсказуемым последствиям.
Дублирование работы опять же. Постановка тега на целевой репозиторий плюс прописывание его в инфраструктурном.
Тайные знания. Не ознакомленный со схемой инженер может не сообразить что нужно пойти в репу и поправить там файл.
В принципе, если у вас медленные процессы и вы редко релизитесь, это наверное допустимо.