Когда ты нанимаешь людей новых людей, они уже скорее всего знают терраформ. Твой велосипед они не знают. А следовательно быстрее станут приносить пользу.
На своем велосипеде ты собираешь все грабли, которые в стандартном инструменте уже собраны и обработаны.
В случае изменения АПИ, добавления новых ресурсов и т.д. тебе не нужно ничего допиливать, т.к. огромное комьнити (в т.ч. сам амазон) делают стандартный инструмент.
Если для вас превознемогать это прочесть документацию к стандартному инструменту это превознеможение, то вы никчемный инженер.
При наших размерах на это уходило около 20 минут, а до следующего изменения нужно было выждать час — мы упирались в лимиты Github-а на количество обращений к API.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться со стейтом? Что это такое, как его разделить, например.
Да и синтаксис не зашел. Описание чего угодно довольно многословное.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться с модулями? Как их писать и сделать из них нужный формат ресурсов, например.
И когда теперь понадобилось кому-то дать права, мы не можем это сделать. Ведь Terraform про него ничего не знает!
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться с импортом ресурсов. Как добавить созданный руками ресурс в терраформ 1 командой, например.
The mission of the Open Container Initiative (OCI) is to promote a set of common, minimal, open standards and specifications around container technology.
Что касается CNF, то в kubernetes такая же история, для runtime они поддерживают любой OCI, для network поддерживают любой CNI (https://github.com/containernetworking/cni), опять таки никаких монолитных кусков.
2k18
@
Docker уже одной ногой в могиле
@
Контейнеры даже в банках и прочих энтерпразайх
@
На хабре появляются статьи "Что такое контейнеры и как запускать докер"
Все так, но навскидку в 90% случаев, feature branch это интеграция 1 раз когда фича сделана. В противном случае зачем вам ветка для коммитов только этой фичи?
It's important to note that, most of the time, feature branching like this is a different approach to CI. One of the principles of CI is that everyone commits to the mainline every day. So unless feature branches only last less than a day, running a feature branch is a different animal to CI.
Не, не, различие тут не "верно"/"вернее". Просто написанное вами в статье неверно.
Я это подразумевал
Сомневаюсь, поскольку дальше вы пишите, что фичебранчи это best practice. Хотя это в принципе противоречит CI подходу. Думаю, что вы просто никогда не читали даже статьи в Википедии с определением CI.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Да нет, прикол вовсе не в том, чтобы собирать каждый день. Прикол в том чтобы мерджить каждый день (даже если ты не доделал фичу, ты мержишь в конце дня). А это намного сложнее.
А настройка билд-сервера это тривиальная задача, которая в принципе не про CI.
Best practice современной разработки — фичебранчи и пулреквесты.
Это руководство для мастера, который устойчив к падению нод в датацентре, но не всего датацентра. Да и вообще не ясно как это сделать поверх etcd. Ведь если у меня 2 датацентра, а для консенсуса RAFT требует 2/3, 3/5, и т.д., то как тут сделать fault tolerant etcd. Об этом же написано в issue https://github.com/kubernetes/kubernetes/issues/21124
В общем не путайте людей, в kubernetes все еще этого нет.
Можно ссылку на руководство? Вы уверены что речь идёт о мастере, который задеплоен на несколько датацентров (aka availability zone) и он остаётся доступен при падении 1 из них? Вроде бы этим занимается подпроект Ubernetes.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться со стейтом? Что это такое, как его разделить, например.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться с модулями? Как их писать и сделать из них нужный формат ресурсов, например.
Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться с импортом ресурсов. Как добавить созданный руками ресурс в терраформ 1 командой, например.
Отлично! Long $AAPL
не может :D
https://www.opencontainers.org/faq#faq1
Вот тут можно посмотреть набор каких стандартов и реализаций они уже сделали (каждая реализация — отдельный тул, а не комбайн!) и что планируют: https://www.opencontainers.org/about/oci-scope-table
Что касается CNF, то в kubernetes такая же история, для runtime они поддерживают любой OCI, для network поддерживают любой CNI (https://github.com/containernetworking/cni), опять таки никаких монолитных кусков.
Да и по поводу билдов, уже есть https://github.com/projectatomic/buildah и https://github.com/openshift/source-to-image, которые билдят OCI. С фичами, которые мы ждем в Docker уже 5-й год (типа mount volume во время билда). Короче закапывайте.
2k18
@
Docker уже одной ногой в могиле
@
Контейнеры даже в банках и прочих энтерпразайх
@
На хабре появляются статьи "Что такое контейнеры и как запускать докер"
Все так, но навскидку в 90% случаев, feature branch это интеграция 1 раз когда фича сделана. В противном случае зачем вам ветка для коммитов только этой фичи?
По поводу чем плох feature branch и почему этот подход не совместим с CI можно почитать тут, от одного из авторов термина https://martinfowler.com/bliki/FeatureBranch.html
Не, не, различие тут не "верно"/"вернее". Просто написанное вами в статье неверно.
Сомневаюсь, поскольку дальше вы пишите, что фичебранчи это best practice. Хотя это в принципе противоречит CI подходу. Думаю, что вы просто никогда не читали даже статьи в Википедии с определением CI.
Да нет, прикол вовсе не в том, чтобы собирать каждый день. Прикол в том чтобы мерджить каждый день (даже если ты не доделал фичу, ты мержишь в конце дня). А это намного сложнее.
А настройка билд-сервера это тривиальная задача, которая в принципе не про CI.
А как же https://trunkbaseddevelopment.com/ ?
Для того что написано в статье (тестирования chef кукбуков) можно обойтись kitchen + docker. Так что в полне себе замена.
.
Поправил, спасибо.
Это руководство для мастера, который устойчив к падению нод в датацентре, но не всего датацентра. Да и вообще не ясно как это сделать поверх etcd. Ведь если у меня 2 датацентра, а для консенсуса RAFT требует 2/3, 3/5, и т.д., то как тут сделать fault tolerant etcd. Об этом же написано в issue https://github.com/kubernetes/kubernetes/issues/21124
В общем не путайте людей, в kubernetes все еще этого нет.
Можно ссылку на руководство? Вы уверены что речь идёт о мастере, который задеплоен на несколько датацентров (aka availability zone) и он остаётся доступен при падении 1 из них? Вроде бы этим занимается подпроект Ubernetes.
Потому я и написал:
Про CloudWatch дал ссылку на тутлориал в статье.