Это я видел, да (я, собственно, упомянул его в оригинальном вопросе). Суть в том, что я не хочу, чтобы автоскейлящиеся машины выписывали себе весь репозиторий. Там же могут быть достаточно эрогенные данные, которые конкретно этому инстансу видеть не следует.
Извините, но эта х… ня радость по запросу «erlang + alternative carrier implementation» предложила мне усыновить ребенка. Это нормально? Она считает, что мне просто нечем заняться?
Выкатвают или не выкатывают программисты код в продакшн — вопрос достаточно многогранный. Равно как и вопрос, кто именно принимает первые меры на продакшоне. Все зависит желаемой скорости релизов. Достичь скорости хотя бы пары релизов в день без тесной интеграции работы админов/девелоперов — очень проблематично.
А за истории, когда программисты не знали что делать, а сисиадмины знали — пинка надо дать таким программистам. «fd-шки закончились» — из-за чего они закончились? Девелопер упорол косяк и решил, что файл можно и не закрывать? Или не поставил админов в известность о допустимых рамках нагрузки? Или админы были проинформированы, но внезапно на это забили? Или не забили, но не смогли в нужный момент предпринять какие-либо мероприятия, связанные со скейлингом, потому что программист пару недель назад (разрабатывая код) сказал: «Я же программист, я не хочу знать ни про какой скейлинг и fd-шки». Кто, вообще, тогда ему сказал, что он программист? Он не знает, что такое fd-шки и почему они заканчиваются. Он не знает, что такое OOM-killer и не понимает, к кому и когда тот приходит. Не знает как работает выделение памяти в linux'е и почему трещит swap… Это правда программист такой? Какую систему он может спроектировать, если не может даже обслужить уже готовую и запущенную систему?
Насчет конкретно бэкапов — ничего не могу возразить. Да, это больше по части админов. Но «что нужно делать, когда система падает» — этого лучше разработчиков уж точно никто знать не может. Все остальные пункты конкретно этого списка точно так же берут начало именно у разработчиков.
Накат обновлений отнимает много времени и сил?
Разработчики не должны предусмотреть, что их систему еще нужно будет обновлять? Не должны были обеспечить простоту апгрейда и (в идеале) отсутствие даунтайма?
Система рушится даже от небольшого обновления?
Разработчики не должны планировать релизы таким образом, чтобы обновления не ломали продакшн?
Выкатывали ли вы когда-нибудь сломанный код на продакшн, причём это становилось известно только после жалоб пользователей?
Не разработчики ли должны покрывать тестами то, что пишут? И не должны ли они обеспечивать удобство тестирования коллегам из QA?
Знаете ли вы, что именно нужно делать, когда система падает? Как добраться до бэкапов и восстановиться из них?
Это я уже выше прокомментировал. Откуда админы должны знать, что нужно делать, если разработчики не знают?
Проводите ли вы больше времени за сменой окружений, повторных выполнений одних и тех же команд, запуска каких-то утилит – чем за самим написанием программ?
Ну опять же, кто должен поддерживать окружение в консистентном состоянии, если не те люди, для которых это окружение, вообще создается?
А я ж не против. Я отнюдь не критикую ваш пост, и более того, считаю его достаточно полезным в плане расстановки акцентов. Докер сейчас каждый интерпретирует как угодно и пытается им заткнуть любые свои проблемы. Вы вполне конкретно делаете упор на то, что докер — средство доставки релизов на сервер. Капитанское утверждение? Я думаю, что да. Но тем не менее, люди пытающиеся использовать докер, почему-то часто игнорируют это самое основное предназначение докера. И я уверен, что с этой точки зрения Ваш пост окажется этим людям полезен.
Я (неявно) подразумевал лишь то, что про докер, как про новую, сырую технологию, лучше писать не в духе «как Вам нужно сделать», а «как мы сами сделали, что у нас было изначально, и почему в итоге у нас получилось так, как есть» =)
Не могу сказать, что пост очень полезный, в нем явно побывал КО. Но то «самое интересное», о чем вы написали (сети, orchestration, discovery) — достаточно специфичные вопросы, не имеющие прямого отношения к докеру. Для каждой из этих проблем есть свои готовые и очень работоспособные решения. Нужны сети — можно смотреть weave или flannel. Нужен discovery — берете etcd, zookeeper и всякие прочие consul'ы. Orchestration — вообще отдельная тема, и контейнеры тут, по-сути, не вносят ничего нового — в крайнем случае, никто не мешает раскатывать контейнеры тем же ansible или puppet/mcollective. Все эти вопросы каждый решает по-разному, и скорее всего, исходит из уже имеющейся инфраструктуры.
А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.
что кроме умения играть в шахматы приобретают хорошие шахматисты?
Думаю, что ничего. Но все-таки подозреваю, что некий программист, обладающий определенным набором профессиональных скиллов и одновременно с этим еще хорошо играющий в шахматы, будет лучше и быстрее решать рабочие задачи, чем программист с тем же набором скиллов, но не умеющий играть в шахматы.
Мде… О самом очевидном варианте я и не подумал. Спасибо. Единственное, что меня смущает — невозможность со стороны (т.е., с машины, которая запускает новый инстанс) понять, готов инстанс провижониться, или еще нет. Получается, что остается только ломиться ansible'ом на этот инстанс до тех пор, пока он-таки не примет соединение?
Вот я именно поэтому и выбрал lumosity. У меня очень сильно хромает рабочая память. Стоит отвлечься на что-то постороннее секунд на 10, после этого могу уже и не вспомнить, чем занимался до этого. Ну и как факт, это сильно ушатывает problem solving. Прикинуть что-то в уме (представить взаимодействие систем, например) бывает очень тяжело. А география, столицы всякие — по-моему, это что-то из той области, где достаточно просто прочитать раз, и оно само запомнится.
Все это, конечно, увлекательно и интересно. Но эффективность таких тренировок лично у меня вызывает сомнения. Пользуюсь lumosity уже три месяца. Не халтурую. Упражнения выполняю качественно. Оно мне рисует всякие графики типа: «Смотри, какой у тебя прогресс, вон, как ты все теперь быстро делаешь». А толку-то тем временем — ноль. Память не улучшилась. Скорость — где была, там и осталась. Как по мне — это просто игрушки, не призванные ничего улучшать или тренировать.
Кто-то может поделиться обратным опытом?
У меня нубский вопрос. Например, я для конфигурирования машин в aws ec2 использую puppet. Каждый раз, когда поднимается новая машина, она самостоятетельно идет к puppet master'у и выписывает у него свою актуальную конфигурацию. Как этого можно добиться с ansible? Я видел, что там есть некий ansible pull. Но как я понял, он тупо копирует себе весь репозиторий (даже с теми деталями, которые конкретной машине видеть не желательно).
Как, вообще, в случае с ansible принято осуществлять провижонинг машин, которые скейлятся автоматически?
Ого. Даже «Хоронитель V» тут затесался. Во времена моей работы в Гэндальфе я даже пытался реанимировать это существо — безрезультатно. Можно закапывать. Последние коммиты в него были сделаны, наверное, лет 10 назад уже и тайные знания о нем (как и о его оригинальных разработчиках) скрыты под тостым слоем пыли.
х… нярадость по запросу «erlang + alternative carrier implementation» предложила мне усыновить ребенка. Это нормально? Она считает, что мне просто нечем заняться?А за истории, когда программисты не знали что делать, а сисиадмины знали — пинка надо дать таким программистам. «fd-шки закончились» — из-за чего они закончились? Девелопер упорол косяк и решил, что файл можно и не закрывать? Или не поставил админов в известность о допустимых рамках нагрузки? Или админы были проинформированы, но внезапно на это забили? Или не забили, но не смогли в нужный момент предпринять какие-либо мероприятия, связанные со скейлингом, потому что программист пару недель назад (разрабатывая код) сказал: «Я же программист, я не хочу знать ни про какой скейлинг и fd-шки». Кто, вообще, тогда ему сказал, что он программист? Он не знает, что такое fd-шки и почему они заканчиваются. Он не знает, что такое OOM-killer и не понимает, к кому и когда тот приходит. Не знает как работает выделение памяти в linux'е и почему трещит swap… Это правда программист такой? Какую систему он может спроектировать, если не может даже обслужить уже готовую и запущенную систему?
Разработчики не должны предусмотреть, что их систему еще нужно будет обновлять? Не должны были обеспечить простоту апгрейда и (в идеале) отсутствие даунтайма?
Разработчики не должны планировать релизы таким образом, чтобы обновления не ломали продакшн?
Не разработчики ли должны покрывать тестами то, что пишут? И не должны ли они обеспечивать удобство тестирования коллегам из QA?
Это я уже выше прокомментировал. Откуда админы должны знать, что нужно делать, если разработчики не знают?
Ну опять же, кто должен поддерживать окружение в консистентном состоянии, если не те люди, для которых это окружение, вообще создается?
Я (неявно) подразумевал лишь то, что про докер, как про новую, сырую технологию, лучше писать не в духе «как Вам нужно сделать», а «как мы сами сделали, что у нас было изначально, и почему в итоге у нас получилось так, как есть» =)
А что за бага с уничтожением netns? Мы в контексте докера долго бились с багами в OOMKiller'е. Его приход с ненулевой вероятностью мог завесить хост намертво. А вот про уничтожение netns как-то не слышали пока ничего.
Думаю, что ничего. Но все-таки подозреваю, что некий программист, обладающий определенным набором профессиональных скиллов и одновременно с этим еще хорошо играющий в шахматы, будет лучше и быстрее решать рабочие задачи, чем программист с тем же набором скиллов, но не умеющий играть в шахматы.
Кто-то может поделиться обратным опытом?
Как, вообще, в случае с ansible принято осуществлять провижонинг машин, которые скейлятся автоматически?
Удивительно, как Вы его, вообще, нашли.