кто напомнит как ансиблом через запароленый ssh ключ деплоить =_=

гугл что-то говорит про --private-key. Точно помню, что запускал так ансибл, но у меня вроде через env это как-то делалось.

https://about.gitlab.com/resources/scaling-enterprise-devops/

Гитлаб раздает книжку по девопс

"Маркетинговый буллшит" и вода... Имхо конечно

а почему в терраформе я не могу указать, что хочу создать инстансы в конкретной зоне? например в us-east-2a пишет * provider.aws: Not a valid region: us-east-2a но если указать без буквы us-east-2, то ошибки нет, но тогда в рандомной зоне создает..

availability zone указывается сетью

availability zone указывается сетью

VPC?

хотя нет, есть ещё availability_zone - (Optional) The AZ to start the instance in.

ааа

вот да, похоже это и нужно, спасиб

у меня просто везде нужная подсеть VPC указана где важна AZ

то есть можно и через подсеть их создавать? а сами подсети насколько помню можно привязывать к AZ?

подсети создаются в конкретной AZ

так что когда указываешь подсеть, то подразумевается её же AZ

так что когда указываешь подсеть, то подразумевается её же AZ

понял) изи

так что когда указываешь подсеть, то подразумевается её же AZ

кстати, а я ж могу вот так вот спаунить и удалять t2.micro инстансы сколько хочу? нет же ограничений на подобные действия?

нету

фух

а то самый первый раз когда был акк начудил себе

что за месяц в итоге бабки сняло с карты)))

натренировался блин

https://medium.com/@valyala/victoriametrics-creating-the-best-remote-storage-for-prometheus-5d92d66787ac

подскажите, пожалуйста, из опыта: плохо ли держать все сервисы типа jenkins/nexus/nagios в контейнерах? нужно ли выделять для них индивидуальные виртуалки?

подскажите, пожалуйста, из опыта: плохо ли держать все сервисы типа jenkins/nexus/nagios в контейнерах? нужно ли выделять для них индивидуальные виртуалки?

Сначала ответь себе на вопрос - а так ли они нужны именно в контейнерах? Если нет веской причины, то я не вижу смысла их туда засовывать.

Иначе получится докер ради докера

А сервисы мониторинга я бы вообще на отдельном физическом хосте держал.

подскажите, пожалуйста, из опыта: плохо ли держать все сервисы типа jenkins/nexus/nagios в контейнерах? нужно ли выделять для них индивидуальные виртуалки?

Нет, не плохо. Бекапы нужны такие же как отдельные тачки. Высоконагруженный сервер стоит иметь отдельно, но мелочь до 20-30 серверов и железок я бы поднял именно докером рядом с остальными служебными тачками

К тому же бекапить там только скуль, а разворачивается он подкладыванием дампа в нужное место

Сначала ответь себе на вопрос - а так ли они нужны именно в контейнерах? Если нет веской причины, то я не вижу смысла их туда засовывать.

1. чтобы легко запускать сервис. легко переносить с debian на amazon linux если новый заказчик потребует. 2. чтобы с легким сердем ставить/обновлять любые пакеты которые потребует отдельный сервис. откатываться на предыдущую рабочую из предыдущего docker-образа. 3. чтобы держать все сервисы на одном большом сервере и экономить ресурсы если выделил на виртуалку 8 гб RAM а он будет использовать 2. 4. чтобы перезапускать контейнер, а не целый сервер. если починить нужно срочно, но не ясно почему завис сервис.

А сервисы мониторинга я бы вообще на отдельном физическом хосте держал.

какие могут быть проблемы если держать вместе с остальными сервисами? чтобы другие сервисы не повесили сервер с мониторингом?

какие могут быть проблемы если держать вместе с остальными сервисами? чтобы другие сервисы не повесили сервер с мониторингом?

Да, поэтому.

1. чтобы легко запускать сервис. легко переносить с debian на amazon linux если новый заказчик потребует. 2. чтобы с легким сердем ставить/обновлять любые пакеты которые потребует отдельный сервис. откатываться на предыдущую рабочую из предыдущего docker-образа. 3. чтобы держать все сервисы на одном большом сервере и экономить ресурсы если выделил на виртуалку 8 гб RAM а он будет использовать 2. 4. чтобы перезапускать контейнер, а не целый сервер. если починить нужно срочно, но не ясно почему завис сервис.

большая часть вопросов, которые решают докером, могут быть решены грамотным созданием архитектуры и ее администрированием. Но это отдельный набор skills, которым не владеют developers. и им действительно проще накликать докер контейнер чем разбираться в этой кухне. И владельцу бизнеса легче - "экономия" на еще одной позиции в компании. Докеры как бы "проще" чем найти грамотного сисадмина

спасибо.

большая часть вопросов, которые решают докером, могут быть решены грамотным созданием архитектуры и ее администрированием. Но это отдельный набор skills, которым не владеют developers. и им действительно проще накликать докер контейнер чем разбираться в этой кухне. И владельцу бизнеса легче - "экономия" на еще одной позиции в компании. Докеры как бы "проще" чем найти грамотного сисадмина

Вопрос не для холивара) если есть возможность упростить решение этих вопросов - зачем ими заниматься для большей части мира разработки?

У меня сейчас создаётся ощущение разделения компаний на тех, у кого есть end user/business продукт и тех, кто создаёт инфраструктуры для первых. То есть компаниям, производящим продукт действительно уже нет смысла заниматься низкоуровневым администрированием

большая часть вопросов, которые решают докером, могут быть решены грамотным созданием архитектуры и ее администрированием. Но это отдельный набор skills, которым не владеют developers. и им действительно проще накликать докер контейнер чем разбираться в этой кухне. И владельцу бизнеса легче - "экономия" на еще одной позиции в компании. Докеры как бы "проще" чем найти грамотного сисадмина

Архитектура ты хотел сказать. У админа или скилла не хватит или времени/опыта или это уже не админ

Архитектура ты хотел сказать. У админа или скилла не хватит или времени/опыта или это уже не админ

Инфрастурктура ты хотел сказать?)

Архитектура инфраструктуры, ну)

это все т999. я уверен что ему заменило инфраструктуру на архитектуру пока писал)

ну как уверен. где то на 99%

Инфрастурктура ты хотел сказать?)

Ошибка, архитектор короче и нужен, а не нанимают

Ошибка, архитектор короче и нужен, а не нанимают

таки да. но это нужно понимать что нужен.

в хайпах такого нет

в хайпах такого нет

Разве? Мне казалось наоборот у них архитекторы появляются, а в старых "и сами справимся"

значит мимо меня прошло совсем. вижу хайп на докеры. на архитектора есть позиции конесчно на марките (ради прикола сегодня смотрел) но больше full stack developer (docker)

значит мимо меня прошло совсем. вижу хайп на докеры. на архитектора есть позиции конесчно на марките (ради прикола сегодня смотрел) но больше full stack developer (docker)

А там как с SRE, ищешь по сре, десяток. Ищешь админ и читаешь описание...я точно читаю для админа?

Пример

Хотя это наверно топик для jobs но я туда не хожу:)

Есть тенденция когда архитектор скатывается в менеджера (вот на глазах позиция VP по software development)

Хотя это наверно топик для jobs но я туда не хожу:)

А че не ходишь?

Эт не архитектор, а инженер

Эт не архитектор, а инженер

Архитектор просто неправильно расценивается в России

Обычно архитектор на западе - тот кто может и будет писать бОльшую часть приложения. Заодно и контролируя его дизайн

Скорее такой staff engineer

Обычно архитектор на западе - тот кто может и будет писать бОльшую часть приложения. Заодно и контролируя его дизайн

А кто спроектирует это все?

А кто спроектирует это все?

Он же.

А что, после того как спроектирует, он сразу уволится?

А че не ходишь?

Не нужно. Тяну свою компанию

че за нах? у них там генератор стоит? почему везде формулировки разные, времена/порядок слов, сеошника взяли?

А что, после того как спроектирует, он сразу уволится?

? модернизация? Это вообще бесконечный процесс, изменение инфры под бизнес процессы и новые вызовы..ну ты понял)

? модернизация? Это вообще бесконечный процесс, изменение инфры под бизнес процессы и новые вызовы..ну ты понял)

Только спроектировал и уже рефакторинг? Так себе архитектор. Вообщем не hands on тут почти не бывает, а чем выше должность, тем больше hands on

Я лично не понимаю как архитектор может быть не инженером

И не быть hands on

И не быть hands on

Без рефакторинга и 'делаем так а так отрефакторим' продует выйдет или поздно или никогда

Или по другому - самое полное описание продукта - это сам продует. Но это уже scrum & agile зона. Напряжно когда ТЗ меняется постоянно, но и ожидания от продукта не стоят на месте. А ещё обратная связь с конечным потребителем ключево-важно в создании конкурентного продукта

Или по другому - самое полное описание продукта - это сам продует. Но это уже scrum & agile зона. Напряжно когда ТЗ меняется постоянно, но и ожидания от продукта не стоят на месте. А ещё обратная связь с конечным потребителем ключево-важно в создании конкурентного продукта

Но не сразу же после имплементации

Но не сразу же после имплементации

Ну скорее всего постоянно

Ещё напряжнее, когда архитектор постоянно меняет архитектуру, причём в критических местах.

Ещё напряжнее, когда архитектор постоянно меняет архитектуру, причём в критических местах.

Это скорее всего недостаток опыта или хайп хантинг

Хотя могут быть случаи когда business requirements так поменялись что с старой архитектурой их не удовлетворить

Это скорее всего недостаток опыта или хайп хантинг

Опыта, думаю. Я вообще про конкретный проект, над которым пришлось работать, и архитектор там был как раз свежеконвертированный из разработчика.

Банальное : а данных у нас будет не 1м записей а 100м записей

Там перконщики на мускул 8 подняли 1ккк таблиц в одной базе, на ZFS :)

давно его не колупал. сегодня прям чет пробило вспомнить свои патчи. например Bug #65104

он же у перконы #893348

=)

Без спама по утрам будет скучно