Как стать автором
Обновить
12
0

Infrastructure Engineer

Отправить сообщение
  1. Когда ты нанимаешь людей новых людей, они уже скорее всего знают терраформ. Твой велосипед они не знают. А следовательно быстрее станут приносить пользу.
  2. На своем велосипеде ты собираешь все грабли, которые в стандартном инструменте уже собраны и обработаны.
  3. В случае изменения АПИ, добавления новых ресурсов и т.д. тебе не нужно ничего допиливать, т.к. огромное комьнити (в т.ч. сам амазон) делают стандартный инструмент.
  4. Если для вас превознемогать это прочесть документацию к стандартному инструменту это превознеможение, то вы никчемный инженер.
При наших размерах на это уходило около 20 минут, а до следующего изменения нужно было выждать час — мы упирались в лимиты Github-а на количество обращений к API.

Возможно перед написанием своего велосипеда следовало бы почитать доки и разобраться со стейтом? Что это такое, как его разделить, например.


Да и синтаксис не зашел. Описание чего угодно довольно многословное.

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


И когда теперь понадобилось кому-то дать права, мы не можем это сделать. Ведь Terraform про него ничего не знает!

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

Отлично! Long $AAPL

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

не может :D

https://www.opencontainers.org/faq#faq1


The mission of the Open Container Initiative (OCI) is to promote a set of common, minimal, open standards and specifications around container technology.

Вот тут можно посмотреть набор каких стандартов и реализаций они уже сделали (каждая реализация — отдельный тул, а не комбайн!) и что планируют: https://www.opencontainers.org/about/oci-scope-table


Что касается CNF, то в kubernetes такая же история, для runtime они поддерживают любой OCI, для network поддерживают любой CNI (https://github.com/containernetworking/cni), опять таки никаких монолитных кусков.

Все что осталось у docker как технологии, это билд имаджей (но и ему не долго жить)

Да и по поводу билдов, уже есть https://github.com/projectatomic/buildah и https://github.com/openshift/source-to-image, которые билдят OCI. С фичами, которые мы ждем в Docker уже 5-й год (типа mount volume во время билда). Короче закапывайте.

  1. Docker cloud не взлетел https://docs.docker.com/docker-cloud/migration/
  2. Founder свалил https://blog.docker.com/2018/03/au-revoir/
  3. Kubernetes выиграл войну оркестраторов, запили cri-o (https://github.com/kubernetes-incubator/cri-o), а последняя поддерживаемая версия докера в нем 1.12
  4. Сейчас стандартизировали registry (https://github.com/opencontainers/tob/blob/master/proposals/distribution.md) и скоро видимо запилят ванильную реализацию вместо docker registry
  5. Все что осталось у docker как технологии, это билд имаджей (но и ему не долго жить)
  6. CFN и OCI толкают unix way, где каждый компонент это отдельный инструмент, и комбайнам типа docker в этом мире не место.
  7. Умрет компания, никто не будет саппортить докер как продукт. С rethinkdb такое уже было.

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.

По поводу чем плох feature branch и почему этот подход не совместим с CI можно почитать тут, от одного из авторов термина https://martinfowler.com/bliki/FeatureBranch.html

Да, пожалуй так будет вернее

Не, не, различие тут не "верно"/"вернее". Просто написанное вами в статье неверно.


Я это подразумевал

Сомневаюсь, поскольку дальше вы пишите, что фичебранчи это best practice. Хотя это в принципе противоречит CI подходу. Думаю, что вы просто никогда не читали даже статьи в Википедии с определением CI.

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.

Да нет, прикол вовсе не в том, чтобы собирать каждый день. Прикол в том чтобы мерджить каждый день (даже если ты не доделал фичу, ты мержишь в конце дня). А это намного сложнее.


А настройка билд-сервера это тривиальная задача, которая в принципе не про CI.


Best practice современной разработки — фичебранчи и пулреквесты.

А как же 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.

Потому я и написал:


Примечание: я не смотрел на новый AWS ALB, возможно там все по-другому.
Когда мы начинали использовать ECS (конец 2015 года)...

Про CloudWatch дал ссылку на тутлориал в статье.

Kubernetes тоже не лишён минусов, fault tolerant master так и не запилили, например.

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Зарегистрирован
Активность