Учимся готовить Log4j + Logstash + ElasticSearch + Kibana 3 + Auth (Google OAuth2/BasicAuth/CAS Authentication)

Спасибо за статью!

Только зачем все это ставить и настраивать в ручную, когда есть Chef cookbook?

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

Спасибо за статью. А почему бы ещё и источник не указть?

bjorn.tipling.com/if-programming-languages-were-weapons

Обзор: Puppet, Chef, Ansible, Salt

Я думаю, автор не вникал, а просто перевёл.

Chef за 21 день. Часть третья. Chef и AWS

А то, что 'AWS OpsWorks (beta)' вас и вашего заказчика не напрягает?

Я пробовал OpsWorks ещё год назад: поднять окружение с парой инстасов используя Chef кукбуки комьюнити. Ничего сразу не завелось и дебажить было трудно. Может с того момента что-то и изменилось… VPC и ELB нужно создавать руками. В общем это совсем не те стеки, что в Cloud Formation.

Для каждого случая лучше подходит свой инструмент. Так что, если нужна вся гибкость и мощь Cloud Formation, то вы знаете, куда двигаться ;)

Chef за 21 день. Часть третья. Chef и AWS

Отсуствие автоскейлинга опасно для кошелька!

Chef за 21 день. Часть третья. Chef и AWS

1-2-3 инстансами шеф не нужен

Не согласен с вами. Если вы почитаете о том, что такое 'Infrastructure as a Code', и ещё к тому же захотите, чтобы все окружения, начиная с локального у разработчиков до Prod-а имели минимум отличий, то вам нужен будет Chef или что-то другое, позволяющее полностью описать инфраструктуру используя код. И количество серверов тут не играет роли.

Паттерны и антипаттерны Chef

Вы сами это делали?
Ещё один момент: каждая копия будет потреблять ресурсы, т.е. все равно нужны пропорциональные мощности. И я не думаю, что держать отдельный Chef-сервер для окружения из двух срверов — это правильно.

Фильтры захвата для сетевых анализаторов (tcpdump, Wireshark, Paketyzer)

Ещё есть консольная утилита tshark от разработчиков wireshark.
P.S. восстановил статус кво.

Chef за 21 день. Часть третья. Chef и AWS

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

Паттерны и антипаттерны Chef

Да. Вы правильно поняли. Я как раз и ожидал примерно такого ответа. Если точнее, то речь не только о EC2 auto scaling, а о любом кластере и автоматическом добавлении/удалении нод. В Puppet приходится изобретать велосипед, в то время к в Chef есть унифицированное API. Это, на мой взгляд, главное отличие.

Вот пример из community cookbook elasticsearch:

seeds = search(:node, "elasticsearch_cluster_name:#{node[:elasticsearch][:cluster_name]} AND elasticsearch_seed:true").sort_by { |n| n.name }.collect {|n| n["ipaddress"]}

node[:elasticsearch][:seeds] = seeds

Таким простым способом получаем список нод, которые объединяются в кластер. При добавлении/удалении ноды изменится и результат поиска и кластер автоматически перенастраивается.

Паттерны и антипаттерны Chef

А что будете делать, если в монго-реплике будет количество нод меняться, например при авто-масштабировании?

Паттерны и антипаттерны Chef

Трудно разделить их объективно. Оба инструмента позволяют готовить инфраструктуру, автомтизировать любые задачи. Лично для меня, был путь Chef -> Puppet. После Chef-а Puppet кажется более бедным и не таким гибким по функционалу. Но это лишь мое личное мнение. Ещё Chef может предоставлятся как сервис (Enterprise Chef), так что начать его использовать легче.

Ламповый Linux-like терминал в Windows

Во-первых я не говорил, что не разрешает. Некоторые инструменты работают только в Windows.

Во-вторых, см. коментарий

Паттерны и антипаттерны Chef

Это реальный опыт или теоретические изыскания? Я понимаю, что это возможно, но сколько времени понадобится, чтобы заставить несколько Chef-серверов работать на одной ноде?

Паттерны и антипаттерны Chef

А вы занете из каких (и из скольки) отдельных компонентов состоит Chef-server? И каждый из них потребляет реурсы. И не так-то просто их будет впихнуть в один сервер.

Паттерны и антипаттерны Chef

Локальное окружение и dev — обычно разные вещи. А если у вас не так, то значит у вас небольшое количество серверов и участников разработки кукбуков, поэтому вы можете себе позволить запускать клента руками и раскидывать конфигурацию по нескольким сущностям.

Если ещё berkshelf использовать, то указание версий в Chef Environments тоже не будет удобным.

Паттерны и антипаттерны Chef

Не нужно так категорично заявлять.

Вы деньги считать умеете? Заказчик — точно. И если окружение не очень большое, то будет использоваться один сервер. Также, возможен вариант, когда окружения не изолированны полностью и нужно, чтобы Chef сервер знал о них все.

Паттерны и антипаттерны Chef

Ну во первых применится — но не будет выполнена (chef-client сам не узнает про изменения).

Извини, но бред написал. Чисто для теста:

$ knife role edit ftp:

{
  "name": "ftp",
  "description": "",
  "json_class": "Chef::Role",
  "default_attributes": {
  },
  "override_attributes": {
  },
  "chef_type": "role",
  "run_list": [
    "recipe[test1]",
    "recipe[test2]"
  ],
  "env_run_lists": {
  }
}


$ knife ssh "role:ftp" "tailf /var/log/chef/client.log" -x ec2-user -i /home/ec2-user/test.pem
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] INFO: Running start handlers
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] INFO: Start handlers complete.
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] INFO: HTTP Request Returned 404 Object Not Found:
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] INFO: HTTP Request Returned 412 Precondition Failed: {"message"=>"Run list contains invalid items: no such cookbooks test1, test2.", "non_existent_cookbooks"=>["test1", "test2"], "cookbooks_with_no_versions"=>[]}
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] ERROR: Running exception handlers
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] ERROR: Exception handlers complete
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] ERROR: 412 "Precondition Failed"
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] ERROR: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
ip-10-1-12-98.eu-west-1.compute.internal [2014-01-27T18:48:41+00:00] ERROR: Sleeping for 300 seconds before trying again

Паттерны и антипаттерны Chef

Теперь представьте, что вам нужно разделить эти сайты на две роли app_server и blog_server. Ну и как вы собираетесь это тестировать на dev окружении?

Применяю обе роли на ноду в dev окружении.

Если изменить роль, то она применится для всех энвов — об этом и речь в статье.

Можно рискнуть и надеяться, что все будет ОК или перезаписать атрибуты в Chef Environments (сначала на dev, потом на qa и т.д.) и не забыть почистить их после того, как они попадут на продакшн. Не самый лучший вариант.

А зачем чистить атрибуты environment, которые не касаются продакшена (а значит при правильном использовании никогда там не будут видны)? Как раз при тестировании нового функционала закидываете атрибуты в env, тестируете только на нем, и если все ок — выносите в роль.

Здесь речь о CI/CD — когда инфраструктурный код движется от дев к проду. И опять же, в роль нельзя, так как это глобальный конфиг и применится ко всем окружениям.

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

Это никто не заставляет вас делать. Никто вам не помещает сделать:

knife ssh -E dev ‘role:webapp’ ‘sudo chef-client’

Который только затронет dev environment с ролью webapp.

Никто не мешает вообще и по ssh зайти и ручками что-то поменять, но тогда зачем Chef?

Паттерны и антипаттерны Chef

Ты прав, lincore. Я поправлю в статье. Спасибо за замечание.