Магия существовала с незапамятных времен. Он всегда был там, спрятанный у всех на виду, делая удивительные вещи возможными для тех, кто хотел открыть глаза и использовать его силу.

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

Эта близость к магии дает вам возможность видеть истинную природу вещей. Время, например, нелинейно (как считалось вплоть до конца 21 века). Иногда за этим трудно уследить…

Внезапно ты просыпаешься. Или вы приходите в сознание. Какой сейчас год?

• Так что да, вывод по-прежнему красный, я действительно не знаю, что еще делать.
• Какая?

Ты смотришь налево. Н сидит прямо там. Он смотрит на вас с легкой тревогой в глазах.

• У тебя все нормально?
• Да извини.
• Как я уже говорил, я не знаю, почему это не работает.

Вы посмотрите на заклинание, которое он пытается сотворить. Его намерение ясно: он хочет поделиться работой своего клана со всеми разумными существами в этой реальности с помощью портала.

---

# task file for nginx

 

- name: Install nginx

  yum:

    name: nginx

    state: present

Понятно, почему он терпит неудачу. Он не принимает во внимание ограничения среды своего клана. Он должен сначала собрать требования своего заклинания, и он смотрит не туда. На самом деле он вообще не смотрит. Ответ прост. Тем не менее…

Вы задумываетесь на секунду, задаваясь вопросом, научил ли кто-нибудь N, как правильно произносить заклинание.

• Как вы проверяете свою роль?
• Хм…
• Вы тестируете свою роль?
• Да, конечно.
• Как?
• Я запускаю свой код на целевой машине, а затем надеюсь, что он не подведет.

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

• Знакомы ли вы с концепцией разработки через тестирование?
• Да, я всегда так работал, когда занимался разработкой с командой.
• Значит, ты с ним знаком.
• Конечно, L научил меня.

О, знакомое имя. Вам нравится L. Вы вместе сражались в Desaix, до того, как он начал обучать своих учеников военному искусству. Должно быть, он научил N кое-чему. Вы задаетесь вопросом, сможет ли он выжить в суде.

• Почему бы вам не протестировать свой код таким образом?
• Потому что это не Java, это Ansible.
• Так?
• Это не тоже самое.
• Давай начнем сначала. Не возражаешь, если я возьму клавиатуру?
• Нисколько.

Вы используете свою энергию, готовясь произнести свое первое заклинание. Вы снова чувствуете себя живым. Вы находитесь в знакомой местности. Прежде чем вы начнете работать, вам нужен пустой холст, игровая площадка для создания структуры и надежности вашей магии. Изолированное ограждение, которое позволит вам пробовать свои заклинания и которое также следует тем же правилам, что и целевая реальность для заклинания, которое вы пытаетесь создать.

• Вы когда-нибудь слышали о молекуле?
• …хм?
• Это инструмент Python. Это позволяет вам тестировать код Ansible на разных уровнях, используя локальную инфраструктуру.
• Местный? Как виртуальная машина?

Он быстрый. Время сделать выбор. Странник или кит? Кит действительно быстрее.

• Не обязательно. Вы можете использовать разных провайдеров. Vagrant и Docker являются наиболее распространенными, если вы хотите работать локально. Мы собираемся использовать Docker, так как у контейнеров более быстрое время запуска.
• Давай, Докер!

Кит это. Вы концентрируетесь и произносите свое первое заклинание.

$ molecule init role --role-name nginx --driver-name docker

Вы чувствуете поток энергии. В небе образуется водоворот голубой воды, из которого появляется Кит. Он плывет по воздуху, смотрит на вас обоих и громко поет свою песню. Пустой корпус материализуется из воздуха, запирая вас и N внутри него. Кит исчезает из водоворота там, где он появился, прямо перед тем, как сам водоворот исчезает в небытии так же быстро, как и появился.

--> Initializing new role nginx…

 

nginx/

├── README.md

├── defaults

│   └── main.yml

├── handlers

│   └── main.yml

├── meta

│   └── main.yml

├── molecule

│   └── default

│       ├── Dockerfile.j2

│       ├── INSTALL.rst

│       ├── create.yml

│       ├── destroy.yml

│       ├── molecule.yml

│       ├── playbook.yml

│       └── tests

│           └── test_default.py

├── tasks

│   └── main.yml

└── vars

    └── main.yml

Вы чувствуете необходимость проверить N. Он смотрит на то, что вы произвели, и хмурит брови.

• Что вы думаете? Это стандартная структура ролей, не так ли? – наивно спросишь ты
• Да, за исключением каталога molecule со всем этим.

Хороший. Он понимает, что есть разница. Как легко объяснить тот факт, что для управления таким ограждением нужны промежуточные заклинания, чтобы и создать его, и разрушить по желанию? Вы решаете, что сейчас это не важно, вы вернетесь к этому позже.

• Не думайте об этом пока. Давайте посмотрим, правильно ли работает наш тестовый фреймворк.

Вы концентрируетесь и накладываете заклинание на ограждение/детскую площадку.

$ molecule test

--> Test matrix

└── default

    ├── destroy

    ├── dependency

    ├── syntax

    ├── create

    ├── converge

    ├── idempotence

    ├── lint

    ├── side_effect

    ├── verify

    └── destroy

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

• Тестовая матрица? По умолчанию? И что это все за вещи?
• Когда я говорил о тестировании кода Ansible на разных уровнях, я имел в виду именно это. Сценарий по умолчанию — это то, что выполняется, когда вы набираете «тест молекулы» на своем терминале, и он содержит все эти действия: уничтожение, зависимость, синтаксис, создание, сходимость, идемпотентность…
• Да, я умею читать.

Снарки. Он хочет, чтобы вы знали, что он не ребенок. Он созерцает структуру корпуса. Вы ждете некоторое время, пока он снова не начнет говорить.

• Эти… действия выполняются по порядку?
• Да, если вы не говорите иначе.
• Что ты имеешь в виду?

Вы решаете, что сейчас самое время спуститься в кроличью нору.

• Так как я набрал `тест молекулы`, молекула выполняет тестовую последовательность по умолчанию, которая соответствует всем этим действиям. Мы также можем переопределить разные последовательности для разных целей, если тестовая последовательность по умолчанию не удовлетворяет нашим критериям тестирования.
• Разные последовательности? Как пропустить все тесты? Или выполнение только… скажем… линтинга?
• Конечно.

Вы поднимаете руку и щелкаете пальцами. Вы слышите звуки деформации, когда корпус каким-то образом смещается. Все выглядит одинаково, но все ощущается по-другому.

# molecule.yml

---

dependency:

  name: galaxy

driver:

  name: docker

lint:

  name: yamllint

platforms:

  - name: instance

    image: centos:7

provisioner:

  name: ansible

  lint:

    name: ansible-lint

scenario:

  name: default

  test_sequence:

    - lint

verifier:

  name: testinfra

  lint:

    name: flake8

Вы делаете глубокий вдох и снова произносите заклинание.

 $  molecule test

--> Test matrix

└── default

    └── lint

--> Scenario: 'default'

--> Action: 'lint'

--> Executing Yamllint on files found in /private/tmp/test/nginx/...

Lint completed successfully.

--> Executing Flake8 on files found in /private/tmp/test/nginx/molecule/default/tests/...

Lint completed successfully.

--> Executing Ansible Lint on /private/tmp/test/nginx/molecule/default/playbook.yml...

Lint completed successfully.

Как только вы закончите, вы оглянетесь на N. Он поймет, куда вы идете.

• Это было быстрее.
• Да.
• Я думаю, что мы должны добавить некоторые действия обратно.
• Я согласен. Какие?
• Позвольте мне увидеть первую тестовую матрицу, которую мы увидели.

Он тщательно изучает игровые заклинания.

• Почему действие уничтожения выполняется первым?
• Потому что все дело в том, чтобы иметь возможность проверить, работает ли ваша роль во вновь созданной инфраструктуре.
• Да, но это займет больше времени, если мне нужно будет создавать и уничтожать контейнер каждый раз, когда я запускаю свой тест, верно?

Хороший. Он соединяет точки, видя нестандартно. Вы решаете, что теперь вам нравится N немного больше. Достаточно, чтобы продолжить игру.

• Да, но мы займемся этим позже. Просто сконцентрируйтесь на действиях, которые мы должны выполнить, чтобы полностью проверить свою роль.
• Хорошо, тогда нам нужно «уничтожить»… что такое «зависимость»?
• Это позволяет вам вытягивать зависимости из галактики, если они вам нужны.
• Ах, давай пропустим это тогда. В чем разница между «синтаксисом» и «вортом»?
• Действие `syntax` запускает ваш плейбук, используя встроенную в Ansible опцию `–syntax-check`, тогда как `lint` проверяет ваши файлы, используя flake8, yamllint и ansible-lint.
• Итак, `create` использует файл create.yml, который мы только что видели в каталоге molecule внутри роли, верно?
• Да. Он создает контейнер Docker, подходящий для использования Ansible. И `destroy` использует файл destroy.yml. Они оба являются плейбуками, поэтому Ansible управляет этими действиями.
• Ешь свою собачью еду, хорошо. Итак, `conerge` выполняет мою роль в контейнере?
• Вот так.
• Как насчет «побочного эффекта» и «проверки»?
• `side-effect` позволяет вам создавать ситуации, в которых вы сможете протестировать больше вещей, например, отказоустойчивость HA. Я не думаю, что он нам понадобится в этой ситуации. А «проверить» — вот где происходит все волшебство. Вот где выполняются наши модульные тесты.
• Модульные тесты? Какая?
• Вы увидите через секунду.
• Хорошо. Итак, я думаю, нам понадобятся `destroy`, `syntax`, `lint`, `create`, `converge`, `verify` и снова `destroy`. Нет, подождите. Без уничтожения в конце. Вот почему это в начале.
• Как хочешь.

Вы замечаете, что чего-то не хватает, но решаете продолжать, чтобы воспользоваться синергией. Вы вернетесь к этому, в конце концов. Ты снова щелкаешь пальцами, меняя вложение в соответствии с его словами.

# molecule.yml

...

scenario:

  name: default

  test_sequence:

    - destroy

    - syntax

    - lint

    - create

    - converge

    - verify

Вы накладываете заклинание еще раз, используя измененную реальность ограждения. Фейерверк появляется еще раз, на этот раз немного меньше.

 $  molecule test

--> Test matrix

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    └── verify

Н кажется счастливым. Он понимает, как это работает. Вы пользуетесь его мотивацией, чтобы дать ему больше знаний.

• Это будет нашим полным тестовым сценарием. Однако мы не собираемся запускать все это каждый раз при тестировании.
• Хм? Почему бы и нет? Что мы делаем вместо этого?

Знание – сила. Все это знают. Если вы можете быстрее приобретать знания, вы также можете быстрее приобретать силу.

• Потому что мы хотим, чтобы наш цикл обратной связи был как можно короче и быстрее. Итак, мы собираемся «создать» наши ресурсы, «свести» их с нашей ролью Ansible и «проверить», что результаты соответствуют нашим ожиданиям. Вы можете сделать это, набрав «молекула создать», «молекула сходится» и «молекула проверить». Затем, если все заработает, мы запустим всю нашу тестовую последовательность.

Ты позволяешь этому впитаться какое-то время, надеясь, что он не сдастся. Вы смотрите за окно. Идет дождь. Тебе нравится дождь. По крайней мере, на Земле. Это лучше, чем на Венере, где кожа с твоих костей плавится, если ты не накладываешь вокруг себя защитные чары. То есть, если температура или давление не получить вас в первую очередь. Н не сдается. Он смотрит на тебя.

• Ладно, думаю, у меня есть. Давайте создадим контейнер.

Вы снова начинаете призывать Кита, но на этот раз слышите только его песню. Он такой же громкий, как и раньше. Ограждение исчезает и снова появляется вокруг вас.

$ molecule create

--> Test matrix

└── default

    └── create

--> Scenario: 'default'

--> Action: 'create'

Смотришь на N и думаешь о следующих шагах. Это покажется ему знакомым.

• Запустим наши тесты. Они расположены в файле test_default.py в каталоге molecule.

Вы громко хлопаете в ладоши. Когда вы разделяете их, из них исходит поток блестящего зеленого света.

 $molecule verify

--> Test matrix

└── default

    └── verify

--> Scenario: 'default'

--> Action: 'verify'

--> Executing Testinfra tests found in /private/tmp/test/nginx/molecule/default/tests/...

Verifier completed successfully.

Все в порядке, пока. Вернемся к Н.

• Каковы три этапа разработки через тестирование?
• Красный, зеленый, рефакторинг.

L сделал свою работу правильно.

• Превосходно. Что вы пытаетесь достичь?
• Я хочу открыть свое веб-приложение с помощью nginx.
• Что вам нужно для этого?
• Ну, мне нужно установить nginx.
• Тогда переходим к красному.

Вы создаёте сгусток энергии руками и используете его, чтобы создать правило в реальности вольера:

import os

 

import testinfra.utils.ansible_runner

 

testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(

    os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')

 

def test_nginx_is_installed(host):

    # Given

    nginx = host.package('nginx')

 

    # Then

    assert nginx.is_installed

• Это кажется знакомым.
• Это потому, что это так.

Вы хлопаете в ладоши, как минуту назад. Тем не менее, на этот раз появляется красный блестящий свет, когда вы их разделяете.

     $ molecule verify

 

    =================================== FAILURES ===================================

    _________________ test_nginx_is_installed[ansible://instance] __________________

 

    host = <testinfra.host.Host object at 0x10a9a7350>

 

        def test_nginx_is_installed(host):

            # Given

            nginx = host.package('nginx')

 

            # Then

    >       assert nginx.is_installed

    E       assert False

    E        +  where False = <package nginx>.is_installed

 

    tests/test_default.py:14: AssertionError

• Видеть? Это красный. Были хороши. Что дальше?
• Зеленый. Итак, теперь мы добавим задачу, которая нам нужна для установки сервера.

Вы закрываете глаза и концентрируетесь. Структура заклинания N была воссоздана с земли.

---

# tasks file for nginx

 

- name: Install nginx

  yum:

    name: nginx

    state: present

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

 $molecule converge

--> Test matrix

 

└── default

    ├── create

    └── converge

--> Scenario: 'default'

--> Action: 'create'

Skipping, instances already created.

--> Scenario: 'default'

--> Action: 'converge'

 

    TASK [nginx : Install nginx] ***************************************************

    fatal: [instance]: FAILED! => {"changed": false, "failed": true, "msg": "No package matching 'nginx' found available, installed or updated", "rc": 126, "results": ["No package matching 'nginx' found available, installed or updated"]}

Никаких фейерверков. Н кажется обескураженным. Вы думаете о том, чтобы дать ему небольшой толчок. Он это заслужил. Дело не в самой магии, а в контексте. Он не получает исходники для своего портала из правильного индекса. Ему нужен кодекс Эпеля.

• По крайней мере, теперь проще проверить.
• Не грусти. Пакет nginx содержится в репозитории epel-release.
• Какая? Ты мог бы сказать мне это с самого начала, не так ли?
• Если бы я это сделал, мы бы не говорили о тестировании инфраструктуры, не так ли?

Он улыбается. Он входит в игру, чувствует настрой. Ему это нравится.

• Давайте попробуем еще раз.

Вы снова изменяете структуру заклинания, указывая, что вы хотите, чтобы ваш портал был создан в соответствии с инструкциями кодекса Эпель.

---

# tasks file for nginx

 

- name: Install epel release

  yum:

    name: epel-release

    state: present

 

- name: Install nginx

  yum:

    name: nginx

    state: present

Вы произносите заклинание с новой структурой.

$ molecule converge

--> Test matrix

 

└── default

    ├── create

    └── converge

--> Scenario: 'default'

--> Action: 'create'

Skipping, instances already created.

--> Scenario: 'default'

--> Action: 'converge'

…

    PLAY RECAP *********************************************************************

    instance                   : ok=3    changed=2    unreachable=0    failed=0

Заклинание работает, или, по крайней мере, кажется, что оно работает. Фейерверки заставляют воздух вибрировать внутри ограждения. Н кажется счастливым. У него еще нет правильных рефлексов. Можешь ли ты винить его? Это его первое существование, и он только начинает играть с магией. Он не поймет, что его портал еще не активен, он просто ослеплен фейерверком. Пришло время для нового суда.

• Превосходно! Думаю, мы закончили!
• Ага. Вы пробовали?
• Ок, посмотрим. Могу ли я как-то войти в контейнер?
• Да, “молекулярный логин”.

[root@instance /]# curl localhost

curl: (7) Failed to connect to ::1: Cannot assign requested address

• Хм. Но… ах, точно! Я так и не запустил службу.
• Будьте моим гостем, добавьте недостающий код, необходимый для этого.

Он собирается изменить структуру заклинания, когда внезапно останавливается. Он смотрит на тебя.

• Нет. Это неправильный путь. Разве я не могу сначала проверить это?

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

• Конечно, просто добавьте еще один тест.
• Хорошо…

def test_nginx_is_running(host):

    # Given

    nginx = host.service('nginx')

 

    # Then

    assert nginx.is_running

• Кстати, я люблю писать тесты на Python. Это намного проще, чем в Java.
• Не позволяй L услышать, как ты это говоришь. Попытайся.

Вы знаете, что Кит не позволит N уйти с рук, но вы хотите увидеть, как он попытается. Неудача — это часть процесса обучения. Это едва ли не важнее успеха. Это единственный способ научиться вставать и продолжать попытки.

$ molecule verify

    E       AssertionError: Unexpected exit code 1 for CommandResult(command=u'systemctl is-active nginx', exit_status=1, stdout=u'', stderr=u'Failed to get D-Bus connection: Operation not permitted')

N хлопает в ладоши, как вы делали раньше, но света не появляется, когда он разводит руки. Он выглядит как ты, растерянный.

• Хм, это не похоже на хороший красный цвет. Это не ошибка утверждения.
• Нет, это не так. Testinfra (ваша библиотека модульного тестирования Python) использует Systemd, Upstart или SysV для проверки работы служб. Контейнеры Docker не имеют системы инициализации. У них есть Тини, но это работает по-другому.
• Поэтому мне нужно изменить изображение, которое я использую. Есть ли образ Centos, включающий Systemd?
• Да, это называется centos/systemd.
• Иди разберись. Где я могу изменить это?
• В файле molecule.yml. Вам нужно будет указать командную инструкцию контейнера, чтобы запустить Systemd, потому что Molecule переопределяет ее по умолчанию. Вам также понадобится привилегированный контейнер, так как Systemd требует CAP_SYS_ADMIN, а непривилегированные контейнеры не имеют такой возможности.
• Хм, я не совсем все понял, но, думаю, завтра я снова спрошу тебя об этом. Позвольте мне повторить конфигурацию.

platforms:

  - name: instance

    image: centos/systemd

    privileged: True

    command: /usr/sbin/init

Кит обязательно примет это предложение. Вы знаете, что он больше не отклонит ваш вызов. N снова проверяет заклинание.

      $ molecule test

    =================================== FAILURES ===================================

    ____________ test_nginx_is_running_and_enabled[ansible://instance] _____________

 

    host = <testinfra.host.Host object at 0x110adff50>

 

        def test_nginx_is_running(host):

            # Given

            nginx = host.service('nginx')

 

            # Then

    >       assert nginx.is_running

    E       assert False

    E        +  where False = <service nginx>.is_running

 

    tests/test_default.py:20: AssertionError

 

    -- Docs: http://doc.pytest.org/en/latest/warnings.html

    ================ 1 failed, 1 passed, 1 warnings in 6.74 seconds ================

• Готово, мы вернулись к красному цвету. Теперь я внесу изменения, чтобы запустить службу.

Вы улыбаетесь, когда видите N craft. Он еще не готов, но идет полным ходом. Вы чувствуете гордость за него.

• Хорошо, я закончил. Что вы думаете?

Он показывает вам структуру своего заклинания.

---

# tasks file for nginx

 

- name: Install epel release

  yum:

    name: epel-release

    state: present

 

- name: Install nginx

  yum:

    name: nginx

    state: present

 

- name: Start nginx

  command: systemctl start nginx

Вся ваша ранее обретенная гордость оборачивается разочарованием. Это нелепо. Это не может быть серьезно. Он не может быть серьезным. Он должен понимать, что вы не можете бесконечно создавать порталы. Результаты могут быть катастрофическими.

Но потом… ты созерцаешь его. Ты понимаешь, что он устал. Идемпотентность также трудно понять. Бенджамин Пирс преподавал его более 50 лет в Гарварде. Ты помнишь, как Мерлин впервые привел тебя в такое ограждение. Одно только воспоминание об этом заставляет вас чувствовать мурашки по коже на затылке.

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

• Почему бы тебе не попробовать?

Он произносит заклинание сам.

$ molecule converge

--> Test matrix

└── default

    ├── create

    └── converge

--> Scenario: 'default'

--> Action: 'create'

Skipping, instances already created.

--> Scenario: 'default'

--> Action: 'converge'

 

    PLAY RECAP *********************************************************************

    instance                   : ok=4    changed=1    unreachable=0    failed=0

Сразу после фейерверка прямо перед вами обоими появляется зеленый портал. Кажется, это работает.

• Большой. Я сейчас проверю.

 $ molecule verify

--> Test matrix

 

└── default

    └── verify

--> Scenario: 'default'

--> Action: 'verify'

--> Executing Testinfra tests found in /Users/sebiwi/stuff/test/nginx/molecule/default/tests/...

    ============================= test session starts ==============================

    ===================== 2 passed, 1 warnings in 6.70 seconds =====================

Verifier completed successfully.

Зеленый свет повсюду.

• Идеальный! Зеленый!

Или это? Вы решаете дать ему небольшой толчок в правильном направлении.

• Попробуйте запустить весь набор тестов.
• Хорошо

 $molecule test

--> Test matrix

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    └── verify

 

---> Scenario: 'default'

--> Action: 'lint'

--> Executing Yamllint on files found in /Users/sebiwi/stuff/test/nginx/...

Lint completed successfully.

--> Executing Flake8 on files found in /Users/sebiwi/stuff/test/nginx/molecule/default/tests/...

Lint completed successfully.

--> Executing Ansible Lint on /Users/sebiwi/stuff/test/nginx/molecule/default/playbook.yml...

    [ANSIBLE0012] Commands should not change things if nothing needs doing

    /Users/sebiwi/stuff/test/nginx/tasks/main.yml:14

    Task/Handler: Start nginx

Никаких фейерверков, никаких огней.

• Какая? О, это просто ansible-lint, он часто не работает для таких вещей, я просто отключу его для этой задачи.

Вы недоверчиво смотрите, как N «исправляет» структуру заклинания.

---

# tasks file for nginx

 

- name: Install epel release

  yum:

    name: epel-release

    state: present

 

- name: Install nginx

  yum:

    name: nginx

    state: present

 

- name: Start nginx

  command: systemctl start nginx

  tags:

    - skip_ansible_lint

Он заканчивает модификации и снова произносит заклинание.

 $  molecule test

--> Test matrix

 

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    └── verify

 

All steps completed successfully.

Он смотрит на тебя с гордостью. Вы встревожены. Он наивен и безрассуден. Вы понимаете, что пришло время разобраться с ситуацией.

• Мы теперь зеленые. Думаю, мы закончили.
• Не совсем. Раньше ansible-lint говорил, что вы что-то меняете, даже если ничего не нужно делать.
• Да, это потому, что я запускал службу.
• Да, но поскольку вы не используете модуль Ansible, вы выполняете действие каждый раз, когда запускаете свой плейбук.
• Я думал, что Ansible идемпотентный.
• Не совсем. Вы можете сделать идемпотентный код с помощью Ansible. Это не означает, что все, что вы с ним делаете, будет идемпотентным. Некоторые вещи не должны быть идемпотентными.
• Как что?
• Например, развертывание приложений. Вы развертываете новую версию приложения. Он предназначен для того, чтобы что-то изменить.
• Я понимаю. Но эта роль должна быть идемпотентной.
• Безусловно. Вы можете добавить новое действие в набор тестов сценария по умолчанию, чтобы проверить идемпотентность.

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

scenario:

  name: default

  test_sequence:

    - destroy

    - syntax

    - lint

    - create

    - converge

    - idempotence

    - verify

Вы снова произносите заклинание.

$  molecule test

--> Test matrix

 

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    ├── idempotence

    └── verify

 

--> Scenario: 'default'

--> Action: 'idempotence'

ERROR: Idempotence test failed because of the following tasks:

* [instance] => nginx : Start nginx

Н смотрит на тебя.

• Так что на самом деле мы еще не были на зеленом поле.
• Мы не были. Идемпотентность — это поведение нашего кода. Он также нуждается в тестировании.
• Хотя я могу это исправить.
• Покажите мне.

Вы передаете управление ограждением N. Он модифицирует структуру заклинания.

---

# tasks file for nginx

 

- name: Install epel release

  yum:

    name: epel-release

    state: present

 

- name: Install nginx

  yum:

    name: nginx

    state: present

 

- name: Start nginx

  service:

    name: nginx

    state: started

Вы улыбаетесь с облегчением.

• Намного лучше. Попытайся.
• Немедленно.

 $  molecule test

--> Test matrix

 

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    ├── idempotence

    └── verify

 

All steps completed successfully.

• А теперь мы зеленые.
• Да!
• Давайте продолжим наш подход TDD. Красный, зеленый и…?
• Рефакторинг! Видите ли вы какие-либо возможные улучшения в этом коде?
• Ну, вы могли бы использовать свою задачу «Запустить nginx» в качестве обработчика, который запускается при установке nginx, не так ли?
• Да я мог.

---

# tasks file for nginx

 

- name: Install epel release

  yum:

    name: epel-release

    state: present

 

- name: Install nginx

  yum:

    name: nginx

    state: present

  notify: Start nginx

---

# handlers file for nginx

 

- name: Start nginx

  service:

    name: nginx

    state: started

 $  molecule test

--> Test matrix

 

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    ├── idempotence

    └── verify

 

All steps completed successfully.

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

• Вау, здорово получилось! Что-то еще?
• У вас может быть только одна задача «ням» и перебор пакетов, которые вы хотите установить.
• Хороший звонок.

---

# tasks file for nginx

 

- name: Install epel-release and nginx

  yum:

    name: "{{ item }}"

    state: present

  with_items:

    - epel-release

    - nginx

  notify:

    - Start nginx

$ molecule test

...

--> Scenario: 'default'

--> Action: 'converge'

 

    PLAY [Converge] ****************************************************************

 

    TASK [Gathering Facts] *********************************************************

    ok: [instance]

 

    TASK [nginx : Install epel-release and nginx] **********************************

    failed: [instance] (item=[u'epel-release', u'nginx']) => {"changed": false, "failed": true, "item": ["epel-release", "nginx"], "msg": "No package matching 'nginx' found available, installed or updated", "rc": 126, "results": ["No package matching 'nginx' found available, installed or updated"]}

 

    PLAY RECAP *********************************************************************

    instance                   : ok=1    changed=0    unreachable=0    failed=1

• Хм. Думаю, мне нужно установить epel-release, прежде чем я смогу установить nginx. Это не сработает, если я сделаю и то, и другое одновременно.
• Истинный.
• Без тестов я бы этого не понял. Я бы сделал свой рефакторинг, и он бы заработал, так как epel-release уже был бы установлен на моей машине при попытке установить его вместе с nginx в одном задании.
• Верно. Кроме того, с текущей структурой кода вы запускаете nginx не только после установки nginx, но и после установки epel-release.
• Верно. Я не должен. Это был тест, не так ли?
• Может быть.

N возвращает структуру заклинания в прежнюю форму. Вы чувствуете себя расслабленным. Вы всегда чувствуете себя так после создания чего-то впечатляющего. Вы чувствуете то же самое, что чувствовали, когда строили пирамиды, только в меньшей степени. Однако на этот раз настоящим создателем является N. Вы выступали только в качестве катализатора. Знания всегда были внутри N, ему просто нужно было услышать правильные вопросы.

N выглядит усталым, но он хочет продолжать.

• Мы только что прошли полный цикл Red/Green/Refactor. Сладкий!
• Вы хотите сделать еще один?
• Абсолютно!
• Что произойдет, если ваша виртуальная машина будет перезагружена?
• Ничего, nginx все равно будет установлен.
• Будет ли он работать?
• О, нет. Это не будет. Угу.
• Вы должны включить его тогда. Ты знаешь что делать.

N создает новое правило в реальности ограждения.

def test_nginx_is_enabled(host):

    # Given

    nginx = host.service('nginx')

 

    # Then

    assert nginx.is_enabled

Он хлопает в ладоши. Красный свет появляется повсюду.

$ molecule verify

--> Test matrix

└── default

    └── verify

--> Scenario: 'default'

--> Action: 'verify'

--> Executing Testinfra tests found in /Users/sebiwi/stuff/test/nginx/molecule/default/tests/…

 

    =================================== FAILURES ===================================

    __________________ test_nginx_is_enabled[ansible://instance] ___________________

 

    host = <testinfra.host.Host object at 0x103b20fd0>

 

       def test_nginx_is_enabled(host):
            # Given
            nginx = host.service('nginx')

            # Then
    >       assert nginx.is_enabled
    E       assert False
    E        +  where False = <service nginx>.is_enabled

    tests/test_default.py:28: AssertionError
    -- Docs: http://doc.pytest.org/en/latest/warnings.html
    ================ 1 failed, 2 passed, 1 warnings in 7.29 seconds ================

• Красный.
• Иди на Зеленого.

N изменяет структуру заклинания, чтобы она соответствовала ограничениям новой реальности. Теперь у него ясная голова, он знает, чего не хватает.

---

# handlers file for nginx

 

- name: Start nginx

  service:

    name: nginx

    state: started

    enabled: yes

 $  molecule test

--> Test matrix

 

└── default

    ├── destroy

    ├── syntax

    ├── lint

    ├── create

    ├── converge

    ├── idempotence

    └── verify

 

All steps completed successfully.

Зеленый портал появляется перед вами обоими. Вы знаете, что это устойчиво, вы оба тщательно его протестировали. Это настоящее заклинание волшебника. Люди сказали бы, что это один из ваших собственных. Н смотрит на тебя и улыбается.

Статья является переводом blog.octo.com

С появлением Infrastructure As Code (Ansible, Puppet, Heat или Terraform) мы хотели бы воспользоваться всеми передовыми методами, принесенными движением Software Craftsmanship , чтобы гарантировать качество кода нашей инфраструктуры. Каждый профессиональный разработчик знает, что для обеспечения качества кода нужны тесты. Одной из полученных практик является TDD , также известная как Test Driven Development.

Напомним, TDD состоит из: начните с создания теста; проверка его отказа; написание кода, необходимого для успешного выполнения теста; перезапуск теста и проверка его успешности, а также предыдущих тестов и, наконец, рефакторинг кода перед началом нового цикла.

3 основных шага TDD

Преимущество этой практики заключается в обеспечении короткого цикла обратной связи и, таким образом, в обнаружении ошибок как можно скорее. Это также позволяет выполнять требования с минимальной сложностью и, следовательно, разрабатывать лучший код.

Если сегодня инструменты, позволяющие разработчикам выполнять TDD, созрели для большинства языков, то это не относится к инструментам Infra as Code. Мы все еще можем прочитать в очень хорошем посте « Мастер », что сегодня мы можем эффективно писать код Ansible в TDD….

… но что касается инструментов подготовки, таких как Terraform , все по-другому.

Боли ручного теста

Terraform , созданный HashiCorp , позволяет нам определять инфраструктуру на языке высокого уровня и развертывать ее в среде облачных провайдеров, таких как Amazon Web Services или Google Cloud Platform.

Сегодня, когда мы хотим протестировать код, мы выполняем тесты вручную. Мы не можем сделать это локально, вы не можете протестировать установку VPC на своем компьютере с помощью localhost . Мы тестируем непосредственно в наших облачных средах.

Они могут длиться несколько минут, часто включают множество шагов, иногда выполняемых вручную, что вынуждает нас либо ждать, либо выполнять регулярное переключение контекста: тем самым задерживается петля обратной связи. Затем мы должны убедиться, что созданная инфраструктура соответствует нашим ожиданиям. Для этого мы используем веб-консоль или командную строку. Иногда мы подключаемся напрямую к машине, чтобы проверить наличие файла. Потом удаляем эти машины и снова перезагружаем…

То, что мы сделали бы вручную, может быть, несколько раз, чтобы исправить свои ошибки, Терратест помогает нам автоматизировать.

Терратест

Что такое Терратест ? Это библиотека Go , которая помогает создавать и автоматизировать тесты для Infra as Code , написанные с помощью Terraform, Packer для поставщиков IaaS, таких как Amazon, Google или для кластера Kubernetes.

 Terratest разработан американским обществом Gruntwork в партнерстве с HashiCorp, которая открыла более 300 000 строк кода и использует Terratest для поддержки своей кодовой базы. Terratest доступен на Github с апреля 2018 года, вы можете перейти сюда , если хотите поиграть с ним.

Почему стоит использовать Терратест?

Тестирование кода с помощью такой библиотеки, как Terratest, дает много преимуществ, вот неполный список:

• Тестирование поведения сложной инфраструктуры
• Сквозные тесты
• Инфраструктурная документация
• Нет необходимости поддерживать постоянную инфраструктуру iso-prod для тестирования ее модификаций.
• Быстрая обратная связь, позволяющая эффективно исправлять ошибки
• Возможность запускать эти тесты быстро и регулярно
• Обеспечение отказоустойчивости при обновлении версий инструментов
• Возможность тестировать сценарии, подобные cloud-init.
• Проверка развернутых образов AMI

Кроме того, Terratest предоставляет множество примеров в своем репозитории Git, упрощая использование библиотеки.

Как это работает ?

Чтобы написать код Terraform в соответствии с принципами Test Driven Infrastructure, мы будем действовать поэтапно:

• Мы начнем с написания теста с использованием Go в *_test.go , например, instance_test.go . Мы будем внимательны, чтобы делать истинные или ложные утверждения в наших тестах. По принципу TDD сначала проверим, что тест не проходит, выполнив команду «go test instance test_test.go» .
• Затем мы напишем наш код Terraform, описывающий нашу инфраструктуру, стараясь сохранить модульную структуру проекта.
• Мы перезапустим Terratest, на этот раз для развертывания вашей инфраструктуры в вашей любимой IaaS. Имейте в виду, что Terratest действительно строит инфраструктуру. Это заставляет применять терраформ , это, очевидно, может потребовать затрат.
• Terratest проводит тесты. Чтобы проверить соответствие нашей инфраструктуры, библиотека может вызывать конечные точки HTTP, подключаться к машинам через SSH, выполнять команды, загружать файлы, запрашивать API-интерфейсы облачных провайдеров и читать выходные данные Terraform…
• Наконец, тестовая инфраструктура будет уничтожена с помощью terraform destroy .
• Результаты теста отобразятся в консоли.

Руки вверх

Цель: Чтобы поиграть с инструментом, мы протестируем сценарий инициализации экземпляра, подключившись напрямую к машине , чтобы проверить его содержимое.

Монтаж

Чтобы открыть для себя библиотеку Terratest, вы можете клонировать ее репозиторий Git . Репозиторий кода содержит как модули, так и множество примеров. Примеры дают хорошее представление о том, что может сделать инструмент, и являются хорошей отправной точкой.

Поскольку Terratest является библиотекой Go , очевидно, что она должна быть установлена ​​на вашем компьютере. Для установки библиотечных модулей Terratest предпочтительно использовать менеджер зависимостей, такой как dep .

Поэтому мы можем установить модуль, который будет использоваться для тестирования Terraform, следующим образом:

dep обеспечить -добавить github.com/gruntwork-io/terratest/modules/terraform

Или вот так с go get:

зайдите на github.com/gruntwork-io/terratest/modules/terraform

Все зависимости желательно описывать в файле Gopkg.toml , это также позволяет зафиксировать версию зависимостей.

Затем убедитесь, что у вас есть необходимый доступ к вашему облачному провайдеру, в нашем случае мы используем AWS и загружаем переменные среды AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY. Мы также позаботимся о том, чтобы у нас была пара закрытый ключ/открытый ключ для подключения к созданным машинам и чтобы наш открытый ключ был в AWS . В этом примере мы назвали ключ «terratest_key».

Наконец, мы создадим проект с пустыми файлами, структурированными следующим образом:

Структура проекта

Зависимости

Для начала мы используем тестовый пакет Go с хорошо названным «test» и импортируем нужные нам модули в файл instance_test.go :

package test
import (
   "testing"
   "fmt"
   "time"
   "github.com/stretchr/testify/assert"
   "github.com/gruntwork-io/terratest/modules/terraform"
   "github.com/gruntwork-io/terratest/modules/aws"
   "github.com/gruntwork-io/terratest/modules/ssh"
   "github.com/gruntwork-io/terratest/modules/retry"
) 

Первый тест: ключ SSH

Затем мы объявляем нашу первую тестовую функцию, которая должна называться так: func TestXxx(*testing.T) , чтобы ее можно было использовать с командой go test . Мы начинаем с проверки правильности создания машины и наличия ключа SSH.

func TestInstanceSshKey(t *testing.T) {}

Теперь, когда мы написали часть «конфигурации», пришло время действовать. Мы хотим инициализировать наш рабочий каталог Terraform и применить наш код (terraform init + terraform apply) . Именно метод InitAndApply запустит это творение. Мы также хотим уничтожить все наши машины по окончании испытаний (терраформировать уничтожить) . Ключевое слово defer позволяет добавить метод Destroy в список действий, которые будут выполняться при возврате функции.

defer terraform.Destroy(t, terraformOptions)
terraform.InitAndApply(t, terraformOptions)

И, наконец, мы получаем вывод terraform, в котором мы находим имя SSH-ключа экземпляра. Этот ключ позволит нам подключиться с Terratest к машине. Поэтому мы сделаем первое утверждение, чтобы можно было определить этот ключ.

instanceSshKey := terraform.Output(t, terraformOptions, "instance_key")
assert.Equal(t, "terratest_key", instanceSshKey)

Вот наша первая полная тестовая функция:

func TestInstanceSshKey(t *testing.T) {
    terraformOptions := configureTerraformOptions(t)
    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)
    instanceSshKey := terraform.Output(t, terraformOptions, "instance_key")
    assert.Equal(t, "terratest_key", instanceSshKey)
}

• Запустить тест

Следующая команда:

пройти тест instance_test.go

… запускает наш тест и вознаграждает вас радостным :

FAIL: TestInstanceIp (0.27s)

По умолчанию это не очень многословно, поэтому мы повторно запустим команду с параметром -v , чтобы получить более подробную информацию.

Бегло взглянув на логи, мы быстро понимаем, что terratest ничего не создавал, это нормально, мы еще ничего не реализовывали. С другой стороны, мы замечаем в журналах, что он инициализировал рабочий каталог (terraform init) , и теперь мы находим файлы Terraform .tfstate .

• Реализация

Теперь мы хотим использовать Terraform для создания нашего экземпляра EC2. В файле main.tf объявляем следующее:

resource "aws_instance" "example" {
    ami           = "ami-5026902d"
    instance_type = "t2.micro"
    key_name = "terratest_key"
}

Этот простой фрагмент кода описывает экземпляр Centos 7 (описываемый свойством «ami»), t2.micro . И настраивает ключ экземпляра SSH, этот ключ уже есть в AWS, мы его создали и скопировали при установке).

Теперь добавим в файл output.tf , в котором мы указываем вывод кода, имя ключа экземпляра:

output "instance_key" {
    value = "${aws_instance.example.key_name}"
}

• Новая попытка

Мы перезапускаем тесты с параметром -v , что позволит нам получить более полный отчет.

Логи показывают этап инициализации Terraform (init), затем приложение (apply). Мы также видим запрошенный вывод : имя ключа экземпляра. Затем наблюдаем за разрушением машины.

И, наконец, облегчение:

--- PASS: TestInstanceSshKey (73.80s)
PASS
ok      command-line-arguments  73.812s

Есть кеш , поэтому, если вы дважды запустите одну и ту же команду без каких-либо изменений в коде Go, ответ будет мгновенным, но тесты не будут воспроизводиться повторно. Мы по-прежнему можем форсировать выполнение, изменив следующую переменную среды: GOCACHE=off.

Никакого рефакторинга, наш код очень прост.

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

Второй тест: публичный IP

Давайте теперь напишем наш второй тест. Наша конечная цель — подключиться к машине, чтобы проверить наличие файла. Поэтому мы должны убедиться, что экземпляр общедоступен . Начнем с кодирования теста.

Чтобы улучшить модульность, мы напишем тест в независимой функции. Это позволяет нам запускать каждый тест независимо от других, но снижает удобочитаемость выходных журналов. С другой стороны, это требует создания и уничтожения нового экземпляра для каждого теста, а это очень трудоемкая операция.

Давайте создадим новую тестовую функцию: TestInstanceIp. Структура нашего файла instance_test.go теперь выглядит так:

func configureTerraformOptions(t *testing.T) *terraform.Options {...}
func TestInstanceSshKey(t *testing.T) {...}
func TestInstanceIp(t *testing.T) {...}

Мы хотим убедиться, что наш экземпляр имеет общедоступный IP-адрес. И мы хотели бы использовать для этой цели aws- модуль Terratest. Как и в первом тесте, добавим методы для создания и уничтожения нашей небольшой архитектуры:

terraformOptions := configureTerraformOptions(t)
defer terraform.Destroy(t, terraformOptions)
terraform.InitAndApply(t, terraformOptions)

Давайте сначала убедимся, что тест красный. Чтобы получить IP-адрес с AWS, нам нужен идентификатор экземпляра. ID — это выходной параметр Terraform, давайте протестируем и реализуем его восстановление, идентичное SSH-ключу.

Получаем следующее утверждение:

instanceID := terraform.Output(t, terraformOptions, "instance_id")
instanceIPFromInstance := aws.GetPublicIpOfEc2Instance(t, instanceID, awsRegion)
assert.Equal(t, “fake_ip”, instanceIPFromInstance)

Давайте проверим, что наш тест красный: (между двумя результатами много логов)

--- PASS: TestInstanceSshKey (45.02s)
=== RUN   TestInstanceIp
---
--- FAIL: TestInstanceIp (52.22s)
instance_test.go:50:
Error Trace: instance_test.go:50
Error: Not equal:
expected: "fake_ip"
actual : "35.180.230.122"

Действительно, IP машины не «fake_ip» . Наш тест провален, мы можем положиться на него.

• Реализация

Затем мы понимаем, что по умолчанию экземпляры AWS создаются с общедоступным IP-адресом; мы проверим, что IP-адрес, возвращаемый выводом Terraform, идентичен IP-адресу Terratest.

Добавим следующий вывод в output.tf:

output "instance_id" {
    value = "${aws_instance.example.id}"
}
output "instance_public_ip" {
    value = "${aws_instance.example.public_ip}"
}

Затем давайте изменим нашу тестовую функцию TestInstanceIp() , чтобы сравнить два значения.

Вся функция:

func TestInstanceIp(t *testing.T) {
    terraformOptions := configureTerraformOptions(t)
    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)
    instanceIP := terraform.Output(t, terraformOptions, "instance_public_ip")
    instanceID := terraform.Output(t, terraformOptions, "instance_id")
    instanceIPFromInstance := aws.GetPublicIpOfEc2Instance(t, instanceID, awsRegion)
    assert.Equal(t, instanceIP, instanceIPFromInstance)
}

Перезапускаем тесты:

--- PASS: TestInstanceIp (79.52s)
PASS
ok      command-line-arguments  124.562s

Победа, он зеленый!

Хорошо, он зеленый, но детали не очень явные.

Третий тест: содержимое файла

Мы убедились, что экземпляр создан с нашим ключом SSH и общедоступным IP-адресом. Воспользуемся этими тестами сейчас, чтобы протестировать запись в файл скриптом, запускаемым при инициализации машины.

Мы хотим проверить, что файл «/tmp/salut» содержит строку «Hello World».

Мы используем пакет ssh и функцию CheckSshCommandE() для выполнения команды «cat /tmp/salvation» на машине и сравнения ее со строкой символов.

Что дает нам утверждение:

expectedText := "Hello, World"
command := fmt.Sprintf("cat /tmp/salut") // Command executed on target machine
actualText, err := ssh.CheckSshCommandE(t, publicHost, command)
assert.Equal(t, expectedText, actualText)

Теперь мы должны указать Terratest, как подключиться к рассматриваемой машине, чтобы получить ее адрес в качестве вывода. Мы используем пользователя по умолчанию «ec2-user» и ключ SSH нашего агента.

publicIP := terraform.Output(t, terraformOptions, "instance_public_ip")
publicHost := ssh.Host{ Hostname:  publicIP, SshUserName: "ec2-user", SshAgent: true, }

Поэтому мы просим 30 попыток, 1 каждые 5 секунд , игнорируя исключения, чтобы иметь возможность продолжить. Наконец, поскольку запуск экземпляра может занять до нескольких минут, нам нужно убедиться, что Terratest несколько раз попытается подключиться к машине, прежде чем объявить об ошибке.

maxRetries := 30
timeBetweenRetries := 5 * time.Second
description := fmt.Sprintf("SSH to public host %s", publicInstanceDNS)
retry.DoWithRetry(t, description, maxRetries, timeBetweenRetries, func() (string, error) {
    actualText, err := ssh.CheckSshCommandE(t, publicHost, command)
    assert.Equal(t, expectedText, actualText)
    return "", err
})

Вот тестовая функция TestFileContent() :

func TestFileContent(t *testing.T) {
    terraformOptions := configureTerraformOptions(t)
    terraform.InitAndApply(t, terraformOptions)
    defer terraform.Destroy(t, terraformOptions)
    publicIP := terraform.Output(t, terraformOptions, "instance_public_ip")
    publicHost := ssh.Host{
        Hostname:  publicIP,
        SshUserName: "ec2-user",
        SshAgent: true,
    }
    maxRetries := 30
    timeBetweenRetries := 5 * time.Second
    description := fmt.Sprintf("SSH to public host %s", publicIP)
    expectedText := "Hello, World"
    command := fmt.Sprintf("cat /tmp/salut")
    retry.DoWithRetry(t, description, maxRetries, timeBetweenRetries, func() (string, error) {
        actualText, err := ssh.CheckSshCommandE(t, publicHost, command)
        assert.Equal(t, expectedText, actualText)
        return "", err
    })
}

Это довольно утомительно и требует знаний в области программирования на Go. С другой стороны, мы автоматически достигаем того, что сделали бы вручную ( кот на файле).

• Что мы забыли?

Мы запускаем тест: go test -v instance_test.go -run TestFileContent

Running command cat /tmp/salut on ec2-user@35.180.190.131:22
"returned an error: dial tcp 35.180.190.131:22: i/o timeout. Sleeping for 5s and will try again."

К сожалению , порт экземпляра не открыт…

Мы реализуем и назначаем нашему экземпляру группу безопасности, разрешающую подключение SSH к машине с любого IP в файле main.tf :

resource "aws_security_group" "ssh" {
    ingress {
        from_port = "22"
        to_port   = "22"
        protocol  = "tcp"
        cidr_blocks = ["0.0.0.0/0"]
    }
}

Попробуем еще раз: go test -v instance_test.go -run TestFileContent

Новая ошибка:

Running command cat /tmp/salut on ec2-user@35.180.190.131:22
"returned an error: Process exited with status 1. Sleeping for 5s and will try again."

Сообщение не очень значимо, но мы знаем, что не создавали файл. Итак, мы заканчиваем наш main.tf , добавляя скрипт, который пишет в файле /tmp/salut при создании машины:

resource "aws_instance" "example" {
    ami           = "ami-5026902d"
    instance_type = "t2.micro"
    key_name = "terratest_key"
    vpc_security_group_ids = ["${aws_security_group.ssh.id}]"
    user_data = <<-EOF
    #!/bin/bash
    echo 'Hello, World!' > /tmp/salut
    EOF
}

« Вот!» :

Running command cat /tmp/salut on ec2-user@35.180.208.120
--- PASS: TestFileContent (0.61s)
PASS
ok      command-line-arguments  0.623s

Мы реализовали и протестировали запись в файл с помощью скрипта инициализации. В этом упражнении скрипт не тестируется полностью (мы все еще можем проверить разрешения и т. д.), но это уже дает представление о том, чего мы можем добиться с помощью этого инструмента.

Идти дальше

Эти неполные тесты позволили нам увидеть некоторые аспекты Terratest. Немного покопавшись в репозитории, мы нашли примеры более сложных тестов для проверки поведения вашей архитектуры с течением времени, таких как развертывание без прерывания обслуживания.

В нем также описывается, как разделить тесты на этапы с помощью переменных среды, чтобы избежать систематического создания и уничтожения экземпляров между тестами. Кроме того, Terraform генерирует tfstate , файл .json, описывающий состояние инфраструктуры, мы можем использовать его для запуска теста несколько раз без перестроения или деконструкции экземпляров.

Также в этом репозитории будут найдены механизмы для рандомизации регионов, в которых создаются инфраструктуры, чтобы гарантировать, что создание возможно во всех. Мы также узнаем, как сделать имена машин случайными, чтобы избежать конфликтов.

Может быть интересно интегрировать Terratest в платформу непрерывной интеграции и запускать тесты при каждом обновлении кода инфраструктуры. Создание сред только на время проведения тестов более экономично, чем постоянное создание выделенных сред.

Наконец, тот же репозиторий включает тестовые примеры и модули, охватывающие другие сервисы AWS, такие как S3, ARDS, CloudWatch, IAM и VPC.

Не говоря уже о том, что Terratest охватывает и другие инструменты: Packer, GCP и K8.

Бонус: Облачная ядерная бомба

Риск, выявленный Gruntwork , заключается в том, что ресурсы не будут уничтожены после неудачной серии тестов и, следовательно, будут иметь застойные экземпляры среди тех, которые действительно используются. Это представляло для них значительные затраты: ~85%. Поэтому они разработали инструмент Cloud Nuke , который регулярно очищает среду от этих экземпляров, конфигураций запуска, балансировщиков нагрузки и потерянных EIP . Все, что было создано более часа назад, считается потерянным, что дольше выполнения всех тестов. Их тестовая среда использует учетную запись AWS, независимую от других, чтобы избежать риска уничтожения компьютеров в других средах.

Бронирование

• В отличие от других инструментов тестирования кода, таких как кухня или молекула, библиотека не абстрагируется от логики создания, тестирования или разрушения своей среды. Из этого следует, что операторы должны реализовать определенные механизмы, такие как повторные попытки в своих тестах.
• Еще раз: будьте осторожны, облачная среда, в которой Terratest строит тестовую инфраструктуру, должна быть разделена и отделена от других сред. Было бы позором уничтожать производственные машины, пытаясь протестировать свою инфраструктуру…
• В-третьих, для взаимодействия Terratest с тестируемыми облачными сервисами он должен иметь соответствующие права. Это потенциально подразумевает необходимость управлять новым пользователем или мощной ролью и предоставлять ему аккредитацию.
• Отчет о результатах теста либо слишком лаконичен: строка FAIL/PASS в неподробном режиме, либо слишком многословен, отображая все детали создания и уничтожения терраформ, которые переполняют информацию.
• Библиотека не очень хорошо представлена ​​​​на менее «традиционных» сервисах AWS, но, в свою очередь, их чрезвычайно много.

А как насчет других во всем этом?

Есть и другие инструменты для тестирования инфраструктуры, такие как kitchen-terraform , набор плагинов для тестовой кухни, написанных на Ruby, а также совсем молодой ruby ​​rspec-terraform или фреймворк для тестирования Terraform .

Terratest фокусируется на функциональном аспекте всей инфраструктуры, а не на отдельных свойствах этих компонентов. Библиотека фокусируется на автоматизации задач, которые подтверждают поведение, а не наблюдают за ним. Например, мы предпочли бы делать настоящие http-вызовы и анализировать код возврата, чем проверять, работает ли служба httpd на сервере.

Вывод

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

Terratest выполняет свое обещание создания эфемерных сред и автоматизации тестирования. Это гарантирует, что в конце выполнения машины будут уничтожены. Он также позволяет тестировать большое количество параметров на инстансах AWS EC2.

Мы видим, что инструмент заслуживает того, чтобы его было проще использовать, чтобы он был обогащен целевыми сервисами, чтобы отчеты были более удобочитаемыми и чтобы его можно было лучше использовать в масштабе. Мы можем думать, что TDD быстро созреет, и что появление этих новых инструментов демократизирует эту практику, и что вскоре инструменты подготовки можно будет легко протестировать. С этими библиотеками, взаимодействующими с инфраструктурой на императивных языках, можно даже подумать, что код инфраструктуры движется к такой парадигме.

Статья является переводом blog.octo.com

Впервые я изучил Kubernetes (сокращенно «k8s») в 2018 году, когда мой менеджер усадил меня и сказал: «Cloudflare мигрирует на Kubernetes, и вы занимаетесь миграцией нашей команды». Меня это немного пугало, потому что я был хорошим программистом и посредственным инженером. Я знал, как писать код, но не знал, как его развертывать или контролировать в продакшене. Моя степень в области компьютерных наук научила меня всему, что касается алгоритмов, структур данных, систем типов и операционных систем. Он не научил меня ни контейнерам, ни ElasticSearch, ни Kubernetes. Я не думаю, что за всю свою степень написал ни одного файла YAML. Я боялся оп. Я был в ужасе от Kubernetes.

В конце концов я справился и перенес всю инфраструктуру Cloudflare Tunnel с Marathon на Kubernetes. Мне это не нравилось, и я сильно просрочил свой дедлайн, но я многому научился. Сейчас 2022 год, и я возглавляю небольшую команду инженеров, некоторые из которых никогда раньше не использовали Kubernetes. Так что я обнаружил, что объясняю им Kubernetes. Они, похоже, сочли это полезным, поэтому я решил записать его и поделиться им с остальными из вас.

Эта статья предназначена для инженеров, которым необходимо развернуть свой код с помощью Kubernetes, но которые понятия не имеют, что такое Kubernetes и как он работает. Я собираюсь рассказать вам историю о младшем инженере. Мы будем следовать за этим инженером, пока он создает высококачественный сервис, и когда у него возникнут проблемы, мы увидим, как Kubernetes может помочь их решить. Надеюсь, это поможет вам создавать свои собственные сервисы в k8s!

Введение: зачем использовать k8s?

Какую проблему k8s вообще пытается решить? Зачем нам еще одна новая сложная программная система со своими странными именами собственными, схемами YAML и процессом сертификации? Я отвечу на этот вопрос, но прежде чем я это сделаю, нам нужно сделать быстрый шаг назад и вернуться в 2013 год, когда индустрия программного обеспечения впервые стала одержима:

Контейнеры

Допустим, вы хотите развернуть два сервера Python. Одному из них нужен Python 3.4, а другому — Python 3.5. Как их развернуть на одной машине? Вы можете взломать сценарий оболочки вместе, возможно, использовать инструменты, специфичные для Python, такие как venv . Хорошо, это работает. Но это не очень хорошо масштабируется, когда вы начинаете развертывать десятки сервисов Python, особенно потому, что у вас возникают аналогичные проблемы с Node, Ruby или всеми другими языками, которые вы используете.

Вместо этого вы запускаете каждый сервер Python в своем собственном контейнере . Контейнер, как и виртуальная машина, позволяет вашей службе действовать так, как будто это единственная служба на этой машине. Он получает собственную чистую файловую систему, и теперь вам не нужно беспокоиться о конфликтах с другими зависимостями. Большой!

Большое преимущество контейнеров перед виртуальными машинами заключается в том, что они очень легкие. На одной машине можно запускать гораздо больше контейнеров , чем на виртуальных машинах. Почему? Потому что каждая виртуальная машина должна устанавливать свою собственную ОС, но контейнеры могут использовать одну и ту же базовую ОС.

Чтобы узнать больше о контейнерах для начинающих, прочитайте этот .

Теперь вы можете развернуть все свои сервисы на одном компьютере, каждый со своим контейнером, в полной изоляции. Они никак не могут мешать друг другу. Это здорово , пока вы не поймете, что вашим службам действительно иногда нужно общаться друг с другом. Оказывается, позволить процессам обмениваться сообщениями — довольно распространенная вещь, и она имеет решающее значение для вашей работы .. Ваша компания, вероятно, использует сервис-ориентированную архитектуру или, возможно, микросервисы, но в любом случае, вероятно, есть несколько сервисов, которым необходимо обмениваться данными для обработки запросов. Например, внешние интерфейсы, серверные части, балансировщики нагрузки, управление сеансами, аутентификация, права пользователей, ведение журналов и выставление счетов могут быть отдельными службами, которым необходимо взаимодействовать. Если вы поместите все эти сервисы в контейнер, вы сделаете невозможным их координацию — по замыслу.

Оркестрация контейнеров

Блин! У нас есть проблемы. Используя контейнеры, мы построили для каждой службы идеальную маленькую изолированную ячейку, чтобы они не могли обмениваться данными. Но мы слишком хорошо выполнили свою работу, нам действительно нужно, чтобы они общались. Но только определенными способами, которые выбираете вы, программист. Мы не хотим возвращаться к временам, когда еще не было контейнеров, когда все программы делились всем — мы видели, какой беспорядок это создает.

Другая проблема, с которой вы столкнетесь, заключается в том, какие контейнеры следует запускать в первую очередь . Допустим, в вашей компании есть система непрерывной интеграции , которая запускается каждый раз, когда вы объединяете PR с master. Вы можете использовать его для создания нового образа контейнера для каждой фиксации в вашей кодовой базе, упаковки вашего кода и всех его зависимостей (например, библиотек для связывания или конкретной версии Python). Теперь, если ваша фиксация изменяет зависимости кода, образ контейнера этой фиксации будет иметь правильную комбинацию кода и зависимостей. Но теперь у вас есть все эти сотни или тысячи контейнеров. Как вы сообщаете своим серверам, какие контейнеры запускать?

Мы решаем эту проблему с помощью программы оркестрации контейнеров , которая выборочно включает некоторые контейнеры и предоставляет им некоторые ресурсы, включая «связь с другими контейнерами». Фраза «контейнерная оркестровка» — это метафора оркестра. Представьте, если бы музыканты в оркестре не слышали друг друга. Они будут играть с разной скоростью, трубы заглушат гобои, каждый скрипач будет считать себя солистом, и ни один из них не будет играть гармонические партии. Это был бы хаос. Чтобы превратить этот беспорядок из изолированных музыкантов в оркестр, вам нужна структура , а для обеспечения соблюдения структуры вам нужен хороший дирижер.

Программа оркестрации контейнеров позволяет:

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

Контейнеры решают проблему «как мне остановить эти сервисы, мешающие друг другу». Оркестрация контейнеров решает, «как я могу позволить этим службам работать вместе». Они также решают, «какие службы должны работать».

Существует множество различных конкурирующих инструментов оркестровки. Возможно, вы использовали Docker Compose , он прост и встроен в Docker, самый популярный движок контейнеров ¹ . Если вам нужно запускать контейнеры только на одном физическом компьютере, я бы посоветовал использовать Docker Compose. Но, конечно же, современные компании-разработчики программного обеспечения никогда не развертывают программное обеспечение только на одной машине. Во-первых, эта единственная машина, вероятно, не может обрабатывать весь ваш трафик. Во- вторых, даже если бы это было возможно , это была бы единственная точка отказа — если эта машина выйдет из строя, ваши услуги станут недоступны, ваши клиенты не смогут размещать заказы, и вы потеряете деньги. Таким образом, инженерам в реальном мире необходимо организовывать контейнеры на множестве различных физических серверов.

Когда я присоединился к Cloudflare, мы использовали для этого Apache Marathon , но быстро мигрировали на Kubernetes. Это привело к одному большому вопросу:

Почему кубернет?

Kubernetes существует для решения одной проблемы: как запустить m контейнеров на n серверах?

Ее решением является кластер . Кластер Kubernetes — это абстракция. Это большой абстрактный виртуальный компьютер со своим собственным виртуальным стеком IP, сетью, диском, оперативной памятью и процессором. Он позволяет развертывать контейнеры так, как если бы вы развертывали их на одном компьютере, на котором больше ничего не запущено. Кластеры абстрагируются от различных физических машин, на которых работает кластер.

Кластер работает на ваших n серверах. Сервер, являющийся частью кластера Kubernetes, называется узлом .

Хорошая абстракция должна скрывать от вас детали, но давать вам доступ к этим деталям, если вам это действительно необходимо. Как правило, ваши контейнеры не знают, и им все равно, на каком узле они работают — абстракция кластера достаточно хороша. Но если вам действительно нужно, вы можете запросить и проверить различные узлы, составляющие кластер.

У вашей компании может быть один кластер Kubernetes или их может быть много. На определенном уровне масштаба вам может понадобиться несколько кластеров — может быть, один кластер для производства и один для промежуточной обработки, или по одному кластеру в Америке, Европе и Азии. Ваша команда SRE или платформы, вероятно, сообщит вам, в какой кластер следует выполнить развертывание.

Итак, зачем использовать Kubernetes?

• Вы хотите использовать контейнеры, чтобы развертывать свои службы изолированно друг от друга.
• Вы хотите использовать оркестратор контейнеров для управления развертыванием контейнеров и совместным использованием ресурсов между ними.
• Если вы работаете на одной машине, просто используйте Docker Compose.
• Если вы работаете на многих машинах, которые могут включаться и выключаться, и вам необходимо запланировать свои контейнеры на них, используйте Kubernetes.

Решение проблем с Kubernetes

Я собираюсь рассказать вам о различных проблемах, с которыми может столкнуться типичный инженер-программист, пытаясь запустить новую, масштабируемую, отказоустойчивую и высокодоступную веб-службу. Мы рассмотрим стандартные решения этих проблем и способы их решения в Kubernetes. К тому времени, когда вы закончите это, вы, надеюсь, будете знать достаточно, чтобы k8s работало продуктивно.

Кстати, всякий раз, когда я использую слово с заглавной буквы, превращая его в имя собственное, это потому, что оно имеет особое значение в мире k8s, например, Pod или Service. Я дам ссылку на документы для этой концепции при первом использовании.

Проблема: я хочу запустить контейнер

Начнем с простого. Вы работали над проектом с кодовым названием kangaroo, и он готов к развертыванию. Итак, вы создаете образ контейнера для его запуска: kangaroo-backend. На вашем рабочем месте их службы работают в кластере Kubernetes, поэтому вам необходимо развернуть этот контейнер в кластере. Как? Вам нужно определить Kubernetes Pod . Под — это набор из одного или нескольких контейнеров (обычно только один контейнер, хотя и ² ). Поды — это минимальная единица развертывания в Kubernetes. Это самая простая и маленькая вещь, которую вы можете развернуть в k8s. Итак, давайте определим под, который запускает наш контейнер, например:

apiVersion: v1
kind: Pod
metadata:
  name: kangaroo-backend
spec:
  containers:
  - name: kangaroo-backend
    image: kangaroo-backend:1.14.2
    ports:
    - containerPort: 80

Этот YAML определяет новый ресурс k8s, который вы можете развернуть в своем кластере. Все ресурсы, независимо от того, что вы развертываете, имеют четыре свойства:

• apiVersion: какую версию определения ресурса k8s использовать. Определения ресурсов (например, Pod) имеют версию, поэтому комитет Kubernetes может позже изменить определение, не нарушая работу всех, кто использует старую версию. Когда вы пишете API, вы, вероятно, включаете «v1» в начале на тот случай, если позже вам понадобится внести обратно несовместимое изменение. Что ж, комитет Kubernetes делает то же самое.
• kind: все ресурсы относятся к определенному типу — в данном случае Pod.
• метаданные: пары ключ-значение, которые можно использовать для запроса и организации ресурсов в кластере.
• spec: Подробная информация о том, что вы развертываете. У каждого сорта есть спец. Например, ресурс типа Pod должен иметь containersключ с массивом контейнеров, каждый из которых имеет файл image.

Мы развертываем модуль, который представляет собой один или несколько контейнеров (обычно только один), поэтому мы установили kind: Podи должны предоставить правильный файл spec. Здесь наша спецификация говорит, что мы запускаем один контейнер, изображение kangaroo-backend:1.14.2. Мы также сообщаем Kubernetes, что контейнер будет прослушивать порт 80.

ХОРОШО! Если мы сохраним это, поскольку pod.yamlмы можем развернуть его, запустив kubectl apply -f pod.yaml. Поздравляем, вы только что развернули контейнер в своем кластере k8s.

Проблема: что делает мой модуль?

Итак, вы развернули модуль. ХОРОШО. Это работает? Делает ли он то, что вы от него ожидаете?

Вы можете использовать kubectlдля проверки вашего модуля. Во- первых, я предлагаю использовать псевдоним kubectlв kвашем терминале, потому что вы будете его часто использовать. Вы можете выполнить запуск k get pods, чтобы просмотреть список развернутых вами модулей и получить k describe pod <ID>дополнительную информацию об этом модуле. Если ваш модуль регистрируется в stdout/stderr, используйте k logs <ID>для просмотра журналов модуля. Если вы действительно не уверены в поде, вы можете подключиться к нему по SSH, запустив k exec <pod ID> -it -- /bin/bash. Дополнительные советы, подобные этому, можно найти на странице Kubernetes Debug Running Pods .

Проблема: я хочу, чтобы мой контейнер перезапускался при сбое.

Project Kangaroo идет хорошо, но каждые несколько дней происходит сбой. Это важная служба, поэтому ее всегда следует перезапускать при сбое. Если бы это был обычный процесс Linux на обычном сервере Linux, вы могли бы использовать сценарий оболочки для его перезапуска или, возможно, systemd. Но как обеспечить автоматический перезапуск модуля k8s?

Вот где проявляется большая сила k8s: k8s является декларативным, а не императивным . Вы заявляете , что там должен работать этот pod, и если это когда-нибудь не так, Kubernetes это исправит. Таким образом, если модуль выходит из строя, Kubernetes перезапустит его, потому что это возвращает состояние кластера в соответствие с предполагаемым состоянием, которое вы указали в манифесте. Вы можете настроить это, изменив политику перезапуска пода , но разумный вариант по умолчанию всегда перезапускать поды с экспоненциальной задержкой (ожидание 10 секунд, затем 20, затем 40 и т. д.) имеет большой смысл.

Это действительно мощная основная идея Kubernetes: вы просто объявляете, в каком состоянии должен находиться кластер, и Kubernetes это сделает. Таким образом, вы тратите больше времени на проектирование системы и меньше времени на ручное выполнение команд или нажатие кнопок, чтобы воплотить свой дизайн в жизнь.

Проблема: у моего контейнера никогда не должно быть простоев, даже если он выйдет из строя.

Kubernetes перезапускает серверную часть Project Kangaroo при сбое, но эти перезапуски по-прежнему приводят к простою в течение нескольких секунд, и даже несколько секунд — это плохо. Тем более, что однажды у вас возникла петля сбоя из-за действительно странного пограничного случая, и ваш сервис был недоступен на несколько минут. Вы действительно хотели бы, чтобы серверная часть была доступна даже во время сбоев и перезапусков.

Проще всего это сделать с помощью реплик . Вы просто запускаете один и тот же контейнер несколько раз одновременно, т. е. запускаете три реплики, и таким образом, если реплика 1 дает сбой, реплики 2 и 3 все еще могут обслуживать трафик. Да, и система должна автоматически запустить новый контейнер, чтобы довести количество реплик до 3. Таким образом, в следующий раз, когда произойдет сбой, у вас будет полный массив реплик, готовый справиться с ним.

В Kubernetes для этого используется Deployment .

# Standard Kubernetes fields for all resources: apiVersion, kind, metadata, spec
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kangaroo-backend-deployment
  labels:
    app: kangaroo-backend

# The `spec` is where the Deployment-specific stuff is defined
spec:
  replicas: 3

  # The `selector` defines which pods will get managed by this deployment.
  # We tell Kubernetes to replicate the pod matching the label `app: kangaroo`
  selector:
    matchLabels:
      app: kangaroo
      role: backend

  # The `template` defines a pod which will get managed by this deployment.
  template:
    metadata:
      # Make sure the pod's labels match the labels the deployment is selecting (see above)
      labels:
        app: kangaroo
        role: backend
    # The Pod has its own spec, inside the spec of the Deployment. 
    # This spec defines what containers the Pod should run.
    spec:
      containers:
      - name: kangaroo-backend
        image: kangaroo-backend:1.14.2
        ports:
        - containerPort: 80

Развертывание управляет набором модулей. Это конкретное развертывание управляет любыми модулями с меткой app: kangaroo, и оно управляет ими, гарантируя, что всегда есть 3 реплики этого модуля. Мы также можем вложить определение самого пода в это развертывание.

Если вы примените этот манифест Kubernetes, вы увидите, что он создает развертывание. Однако это не создает явно соответствующие модули, поэтому на короткое время ни одна из реплик не работает. Но помните, Kubernetes является декларативным, а не императивным . Итак, Kubernetes замечает, что его кластер не соответствует заявленному вами предполагаемому состоянию (3 реплики). Так что потребуются некоторые действия, чтобы исправить это, например, запуск нового модуля реплики. Как только это действие будет завершено и ваш модуль появится, Kubernetes повторно оценит состояние кластера, заметит, что в нем по-прежнему меньше модулей, чем предполагалось, и создаст новую реплику. Это повторяется до тех пор, пока заданное вами развертывание не произойдет.

Проблема: мой контейнер не справляется с объемом получаемого трафика.

Project Kangaroo становится все более популярным, и ваш бэкенд получает слишком много трафика. Вы знаете решение – реплики. Реплики могут сделать службу более производительной и отказоустойчивой! К счастью, вы уже знаете, как использовать развертывания Kubernetes для репликации вашего контейнера. Таким образом, вы просто настраиваете спецификацию развертывания, увеличивая количество реплик. Теперь ваш сервис может масштабироваться в зависимости от объема трафика.

(Есть даже эластичное масштабирование, где вы можете программно определить какое-то свойство, например, «количество запросов на реплику в секунду должно быть меньше 1000», и позволить Kubernetes автоматически выбирать необходимое количество реплик. Это называется горизонтальным автоматическим масштабированием, и я не собираюсь чтобы покрыть это здесь, но вы можете прочитать больше )

Проблема: мне нужно развернуть новую версию моего бэкенда, не вызывая простоя

Каждую неделю вы выпускаете новую версию бэкенда Kangaroo. В первый раз, когда вы сделали это, вы просто удалили развертывание и создали новое развертывание с более новой версией контейнера kangaroo-backend. Это сработало, но вызвало несколько минут простоя, которого вы действительно пытаетесь избежать. Как вы можете обновить кенгуру версии 15 до версии 16, не вызывая простоев?

Это очень распространенная проблема, поэтому Kubernetes Deployments уже поддерживает ее. Это называется обновлением развертывания , и это легко. Просто отредактируйте развертывание и перейдите kangaroo-backend:1.15на kangaroo-backend:1.16(либо с помощью kubectl editинтерфейса командной строки, либо путем редактирования манифеста YAML, изменения образа контейнера и повторного запуска kubectl apply). Декларативное управление Kubernetes срабатывает и замечает, что развертывание, которое у вас есть в настоящее время (в контейнере kangaroo-backend:1.15), не совпадает с тем, что вы хотите ( kangaroo-backend:1.16). Таким образом, он будет выполнять пошаговое обновление : по одному, он будет

1. Обратите внимание, что фактическое состояние кластера не соответствует заявленной спецификации (недостаточно реплик в версии 1.16).
2. Запустите новый модуль в версии 1.16.
3. Если этот модуль запустится успешно, Kubernetes заменит его на старый модуль в развертывании.
4. Обратите внимание, что есть модуль (kangaroo-backend:1.15), который не является частью какой-либо заявленной спецификации, поэтому приведите систему в соответствие с объявленной спецификацией, остановив модуль.

Это повторяется до тех пор, пока все устаревшие модули не исчезнут и останутся только современные модули.

Проблема: мне нужно направить трафик на все модули в развертывании.

Каждый модуль получает свой собственный IP-адрес кластера (IP-адрес, который имеет значение только в этом кластере Kubernetes — другие кластеры или более широкий Интернет ничего не знают об этих IP-адресах). Таким образом, вы можете отправлять трафик с интерфейса кенгуру на сервер кенгуру, используя этот IP-адрес.

Это работает нормально, пока ваш модуль не перезапустится или у вас не будет развертывания с несколькими модулями, потому что каждый из них будет иметь разные IP-адреса. Как ваши внешние интерфейсы узнают, на какие IP-адреса они должны отправлять кенгуру-бэкенд-трафик? Пришло время для нового вида Kubernetes под названием Сервис.

# The kangaroo-backend Service.
# Other services inside the Kubernetes cluster will address the
# kangaroo-backend containers using this service.
apiVersion: v1
kind: Service
metadata:
  name: kangaroo-backend
  labels:
    app: kangaroo-backend
spec:
  ports:
    # Port 8080 of the Service will be forwarded to port 80 of one of the Pods.
    - port: 8080
      protocol: TCP
      targetPort: 80
  # Select which pods the service will proxy to
  selector:
    app: kangaroo
    role: backend

Развертывание этой службы создает запись DNS в вашем кластере Kubernetes, например my-svc.my-namespace.svc.cluster-domain.example, или kangaroo-backend.kangaroo-team.svc.mycompany.com. Объект службы будет отслеживать, какие модули соответствуют его селекторам. Всякий раз, когда служба получает TCP-пакет на свой port, она перенаправляет его targetPortна соответствующий модуль.

Итак, теперь внешний интерфейс кенгуру будет просто отправлять свои запросы API на это внутреннее имя хоста kangaroo-backend.kangaroo-team.svc.mycompany.comкластера, а преобразователь DNS кластера сопоставит его со службой кенгуру, которая перенаправит его на какой-либо доступный под. Если у вас есть развертывание, оно гарантирует, что у вас достаточно подов для обработки трафика. Хороший!

Примечание. И службы, и развертывания выбирают модули с определенным набором меток, но у них разные обязанности. Сервисы обеспечивают балансировку трафика и обнаружение, а развертывание гарантирует, что ваши модули существуют в правильном количестве и правильной конфигурации. Обычно бэкенды/серверы, которые я развертываю в K8s, имеют 1 службу и 1 развертывание, выбирая одинаковые метки.

Проблема: балансировка нагрузки между подами

Мы только что рассмотрели, как сервис k8s позволяет вам обращаться к набору подов, даже когда поды входят в этот набор или покидают его (например, путем перезапуска или обновления). Если вы подумали «это похоже на балансировку нагрузки», то поздравляю, вы были правы!

Если вы используете службу k8s для маршрутизации трафика к вашему приложению, вы получаете базовую балансировку нагрузки ³ бесплатно. Если модуль выходит из строя, служба прекращает маршрутизацию трафика к нему и начинает маршрутизировать трафик к другим модулям с соответствующими метками (возможно, модулям в том же развертывании). Пока другие модули в кластере используют DNS-имя хоста службы, их запросы будут направляться на доступный модуль.

Проблема: я хочу принимать трафик из-за пределов кластера

До сих пор ваша служба принимала трафик от интерфейсов внутри кластера, используя имя хоста службы. Но эти кластерные IP-адреса и записи DNS имеют смысл только в кластере. Это означает, что другие сервисы в вашей компании могут нормально маршрутизироваться к серверной части Kangaroo. Но как вы можете принимать трафик из – за пределов кластера, например, интернет-трафик от ваших клиентов?

Вы развертываете два типа ресурсов: Ingress и IngressController .

1. Ingress определяет правила для сопоставления внешнего трафика HTTP/S кластера с внутренними службами кластера. Оттуда ваша служба перенаправит его в модуль, как обсуждалось выше.
2. IngressController выполняет эти правила. Ваша компания, вероятно, уже настроила Ingress Controller для вашего кластера. Проект Kubernetes поддерживает и поддерживает три конкретных IngressController (AWS, GCE и Nginx), но есть и другие популярные, такие как Contour , которые я использую.

Настройка IngressController, вероятно, является работой специализированной команды платформы, которая поддерживает ваш кластер k8s, или облачной платформой, которую вы используете. Поэтому мы не будем их освещать. Вместо этого мы просто поговорим о самом Ingress, который определяет правила сопоставления внешнего трафика с вашими сервисами.

Примечание. Удобно, что вы можете определять правила Ingress, которые абстрактно работают с любым конкретным IngressController, поэтому различные проекты могут предлагать конкурирующие контроллеры, совместимые с одним и тем же API Kubernetes.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  ingressClassName: kangaroo
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: kangaroo-backend
            port:
              number: 8080

Это создает Ingress, используя контроллер входящего трафика по умолчанию для нашего кластера. У Ingress есть одно правило, которое сопоставляет трафик, путь которого начинается с /api, с нашим кенгуру-бэкендом. Мы могли бы определить больше правил, если хотим, например, сопоставить /admin с какой-либо службой администрирования. Трафик, который не соответствует каким-либо правилам, обрабатывается по умолчанию вашим IngressController.

Проблема: я хочу ограничить сеть внутри кластера

Вы очень серьезно относитесь к безопасности в Project Kangaroo. Вы хотите проявлять инициативу в отношении безопасности, поэтому думаете: что, если кто-то взломает серверную часть кенгуру с помощью SQL-инъекции или чего-то еще. Вы хотите сдержать ущерб и убедиться, что злоумышленники не могут переключить свой контроль над серверной частью Kangaroo на контроль над другими службами.

Одним из простых способов смягчения последствий является использование сетевой политики Kubernetes для ограничения сетевых разрешений вашего проекта. Вы используете сетевые политики для ограничения:

• Ingress (от кого ваш сервис может получать трафик)
• Выход (кому ваш сервис может отправлять трафик)

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

1. fromговорит, какие виды услуг могут отправлять трафик
2. portsговорит, на какие порты они могут отправлять трафик

В правилах исходящего трафика есть toи ports, определяющие, в какие пункты назначения ваша служба может отправлять трафик и какие порты в этих пунктах назначения разрешены.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kangaroo-network-policy
  labels:
    app: kangaroo
    role: network-policy
spec:
  podSelector:
    matchLabels:
      app: kangaroo
      role: backend
  policyTypes:
    - Ingress
    - Egress
  # Each element of `ingress` opens some port of Kangaroo to receive requests from a client.
  ingress:
    # Anything can ingress to the public API port
    - ports:
        - protocol: TCP
          port: 80
    # Hypothetical example: say your Platform team has configured cluster-wide metrics,
    # you'll need to grant it access to your pod's metrics server. Your company will
    # have examples for this. Assume kangaroo-backend serves metrics on TCP :81
    - from:
        - namespaceSelector:
            matchLabels:
              project: monitoring-system
      ports:
        - protocol: TCP
          port: 81
  # Each element of `egress` opens some port of Kangaroo to send requests to some server
  egress:
    # Say the Kangaroo backend calls into a membership microservice.
    # You'll need to allow egress to it!
    - ports:
        - port: 443
      to:
        - namespaceSelector:
            matchLabels:
              project: membership
              role: api

Проблема: я хочу использовать HTTP/S вне кластера и HTTP внутри кластера

Управление сертификатами TLS может быть головной болью — создание, управление, развертывание и повторное создание этих сертификатов довольно утомительно, и если что-то пойдет не так, вы можете случайно отключить весь трафик к своей службе. Поэтому, если вы уже правильно настроили свои сетевые политики (см. выше), вы решите не использовать TLS в конкретном кластере или пространстве имен. Поговорите со своей командой и посмотрите, имеет ли это смысл для вас.

Если это так, вы, вероятно, все еще хотите разрешить HTTP/S для внешнего трафика — в конце концов, в Интернете нет пространств имен или сетевых политик Kubernetes. Таким образом, вы должны настроить свой Ingress для завершения HTTP/S до того, как он отправит запросы в вашу службу. Это означает, что внешние клиенты будут выполнять рукопожатие TLS с вашим Ingress, а затем ваш Ingress перенаправит открытый текст HTTP в вашу службу.

Проблема: я хочу получить метрики о моем сервисе

Вы, вероятно, захотите собрать метрики о задержке вашего сервиса, количестве ответов HTTP класса 200/400/500 и т. д. Вы можете самостоятельно оснастить свой сервер чем-то вроде Prometheus, OpenMetrics или Honeycomb. Это работает нормально, но вы столкнетесь с двумя проблемами:

1. Когда ваш сервис выходит из строя, вы не можете получить от него метрики
2. Вы будете писать одни и те же метрики для каждой службы, которую когда-либо развертываете. Это становится повторяющимся и шаблонным.

Вместо этого большинство IngressController будут собирать кучу метрик. Например, Contour будет отслеживать каждый HTTP-запрос, который он перенаправляет в вашу службу, и отслеживать задержку и статус HTTP. Затем он предоставляет их в метриках Prometheus , которые вы можете очистить и отобразить в виде графика. Это действительно удобно, потому что вы экономите время, не внедряя эти метрики самостоятельно. И когда ваша служба выйдет из строя, вы узнаете об этом, потому что увидите показатели Contour для этого пространства имен/службы, показывающие всплески задержки или ответы HTTP 5xx.

Проблема: мне нужна изоляция от других проектов, использующих тот же кластер

Ваш проект k8s прошел успешно. Вы отправили проект, всем он нравится. Подходит технический директор и спрашивает: «Как Kubernetes?» Сморгнув слезы, ты говоришь: «Не так уж и плохо». Ваша команда покупает вам кружку с надписью «Лучший писатель YAML».

Другие команды учатся на вашем успехе и начинают развертывать свои проекты в Kubernetes. Однажды они приходят к вам и жалуются, что ваше Развертывание нарушило их Развертывание. Хм? Что случилось?

Получается, вы написали Deployment, который сопоставляет любые pod’ы с метками role: backend. Это прекрасно работает, когда вы единственная команда, работающая в k8s — вы пишете шаблон модуля с меткой role: backend, и он реплицируется в файле Deployment. Что, если другая команда развернет собственный модуль с помощью role: backend? Ваше развертывание будет соответствовать этому поду и начнет воспроизводить материалы другой команды! Что вы должны сделать?

Одним из решений было бы всегда добавлять небольшой префикс к этим меткам, поэтому вместо того, чтобы backendваши команды соглашались использовать такие метки, как kangaroo-backendи emu-backend. Это зависит от того, насколько дисциплинирован каждый, чтобы соблюдать правила. Даже если все согласны, рано или поздно кто-то может ошибиться, оступиться и развернуть что-то с неправильным ярлыком. Это может привести к серьезным проблемам! Представьте, если бы вы случайно воспроизвели сервис, который должен был быть синглтоном!

К счастью, в Kubernetes есть встроенный способ изолировать команды друг от друга. Это называется пространством имен . Они позволяют изолировать команды или проекты друг от друга, чтобы их имена не конфликтовали. Точно так же, как несколько типов могут экспортировать методы с одним и тем же именем, например, String::newи File::new. Просто используйте --namespaceв CLI kubectl, чтобы выбрать, какое пространство имен вы хотите развернуть.

Примечание. В Cloudflare мы обычно используем два пространства имен для каждой команды, например, «предотвращение потери данных — подготовка» и «предотвращение потери данных — производство». Затем, когда мы развертываем новые изменения K8s, мы можем развернуть их на этапе подготовки, чтобы убедиться, что они работают, а затем развернуть их в рабочей среде, зная, что наши изменения не будут мешать другим командам.

Вывод

Веб-приложения сталкиваются с одними и теми же проблемами, независимо от того, где они развернуты. Управление и балансировка нагрузки между репликами, ограничение сетевых привилегий, обновления с нулевым временем простоя — все это не является уникальным для Kubernetes. Возможно, вы уже знаете, как решить их в своей любимой модели развертывания. Kubernetes также предоставляет довольно хорошие готовые решения для их решения, вам просто нужно перевести стандартные решения на жаргон Kubernetes (модули, развертывания и т. д.).

Резюме:

• Под — это минимальная единица развертывания. Модуль запускает один (или несколько) контейнеров.
• Реплицируйте свои модули с помощью Deployments . Это дает вам:
  • Устойчивость к сбоям
  • Последовательные обновления с нулевым временем простоя
  • Масштабирование для увеличения трафика
• Балансировка нагрузки между модулями в вашем развертывании с помощью [Service].
• Ограничьте сетевой доступ вашего модуля с помощью сетевой политики , чтобы уменьшить уязвимую поверхность .
• Сопоставьте внешний трафик с вашим модулем с помощью Ingress .
  • Правила входа сопоставляют определенный тип трафика (протокол, URL-адрес и т. д.) с определенной службой.
  • Правила выполняются IngressController . Администраторы вашего кластера, вероятно, уже настроили его.
• Изолируйте команды и проекты друг от друга с помощью пространств имен .

Большое спасибо Sana Oshika , Jesse Li , Mingwei Zhang и Rina Sadun за действительно полезные отзывы о черновиках этого поста. И отдельное спасибо Тиму и Терину из Cloudflare, которые очень помогли мне научиться понимать и использовать Kubernetes. Они всегда отвечают на вопросы и улучшают опыт разработчиков. Они действительно иллюстрируют, как выглядит отличная команда платформы.

Статья является переводом blog.adamchalmers.com

Узнайте, как настроить поставщика OIDC с помощью EKS и как создать роли IAM для учетных записей служб. Полный исходный код доступен на github .

Обзор

В последнем выпуске EKS (1.13 и 1.14) плоскость управления AWS Kubernetes поддерживает роли IAM для учетных записей служб. Эта функция позволяет нам связать роль IAM с учетной записью службы Kubernetes. Теперь мы можем предоставить временные учетные данные, а затем предоставить разрешения AWS для контейнеров в любом модуле, который использует эту учетную запись службы. Кроме того, нам больше не нужно предоставлять расширенные разрешения роли IAM рабочего узла, чтобы модули на этом узле могли вызывать API AWS.

Прежде чем эта функция была включена, нам приходилось использовать решения kiam или kube2iam. Подробнее о kube2iam можно прочитать в другом моем рассказе .

В этой истории вы узнаете, как настроить EKS, провайдера OpenID Connect (OIDC), роли IAM и сервисные аккаунты с помощью Terraform. Вы также узнаете о проблемах, с которыми я столкнулся во время установки. Для своей реализации я использую EKS 1.14 (экс.1), Terraform 0.12.12, Terraform AWS provider 2.28.1 .

Преимущества

Функция ролей IAM для учетных записей служб предоставляет следующие преимущества:

• Наименьшие привилегии . Благодаря использованию ролей IAM для сервисных учетных записей вам больше не нужно предоставлять расширенные разрешения роли IAM рабочего узла, чтобы модули на этом узле могли вызывать API AWS. Вы можете ограничить разрешения IAM для учетной записи службы, и только модули, использующие эту учетную запись службы, имеют доступ к этим разрешениям.
• Изоляция учетных данных . Контейнер может извлекать учетные данные только для той роли IAM, которая связана с учетной записью службы, которой он принадлежит. Контейнер никогда не имеет доступа к учетным данным, предназначенным для другого контейнера, принадлежащего другому поду.
• Возможность аудита . Доступ и ведение журнала событий доступны через CloudTrail, чтобы помочь обеспечить ретроспективный аудит.

Технический обзор ролей IAM для учетных записей служб

AWS IAM поддерживает федеративные удостоверения с использованием OIDC. Эта функция позволяет нам аутентифицировать вызовы API AWS с помощью поддерживаемых поставщиков удостоверений и получать действительный веб-токен OIDC JSON (JWT). Вы можете передать этот токен в AssumeRoleWithWebIdentityоперацию AWS STS API и получить учетные данные временной роли IAM. Такие учетные данные можно использовать для связи с такими сервисами, как Amazon S3 и DynamoDB.

Kubernetes уже давно использует учетные записи служб в качестве собственной внутренней системы идентификации. Поды могут аутентифицироваться на сервере API Kubernetes с помощью автоматически монтируемого токена (это был JWT, не относящийся к OIDC), который мог проверить только сервер API Kubernetes. Срок действия этих устаревших токенов сервисной учетной записи не ограничен, и смена ключа подписи — сложный процесс. В Kubernetes версии 1.12 была добавлена ​​поддержка новой ProjectedServiceAccountTokenфункции, представляющей собой веб-токен OIDC JSON, который также содержит идентификатор учетной записи службы и поддерживает настраиваемую аудиторию.

Amazon EKS теперь размещает общедоступную конечную точку обнаружения OIDC для каждого кластера, содержащую ключи подписи для ProjectedServiceAccountTokenвеб-токенов JSON, поэтому внешние системы, такие как IAM, могут проверять и принимать токены OIDC, выпущенные Kubernetes. Источник технической реализации .

Внедрение и настройка

С помощью terraform я создал кластер EKS и провайдера OIDC:

### Backend and provider config for reference
terraform {
  required_version = "~> 0.12.12"backend "remote" {
    hostname = "app.terraform.io"
  }
}provider "aws" {
  assume_role {
    role_arn     = var.assume_role_arn
    session_name = "EKS_deployment_session_${var.tags["Environment"]}"
  }version = "~> 2.28.1"
  region  = var.region
}### EKS cluster config
resource "aws_eks_cluster" "cluster" {
  enabled_cluster_log_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"]
  name                      = "${var.tags["ServiceType"]}-${var.tags["Environment"]}"
  role_arn                  = aws_iam_role.cluster.arn
  version                   = "1.14"vpc_config {
    subnet_ids              = flatten([module.vpc.public_subnets, module.vpc.private_subnets])
    security_group_ids      = [aws_security_group.cluster.id]
    endpoint_private_access = "true"
    endpoint_public_access  = "true"
  }
}### OIDC config
resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = []
  url             = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

Вы будете удивлены, но этих двух ресурсов достаточно для настройки вашего кластера EKS и провайдера OIDC.

Вот место, где я часами пытался решить проблему с OIDC, поскольку мои учетные записи службы не могли получить действительные учетные данные. Причина, по которой он не работал, заключалась в отсутствующем отпечатке корневого ЦС. Если вы создаете провайдера OIDC для своего кластера EKS с помощью консоли AWS, отпечаток добавляется автоматически. Однако, когда вы создаете его с помощью terraform, список пуст.

[ОБНОВЛЕНО 28.08.20] Существует три способа получения отпечатка и добавления его в ресурс aws_iam_openid_connect_provider. Решение номер три — единственное, полностью поддерживаемое Terraform и достигаемое с помощью поставщика TLS terraform.

1. Внешний источник данных Terrafor

### External cli kubergrunt
data "external" "thumb" {
  program = ["kubergrunt", "eks", "oidc-thumbprint", "--issuer-url", aws_eks_cluster.cluster.identity.0.oidc.0.issuer]
}### OIDC config
resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.external.thumb.result.thumbprint]
  url             = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

или без использования бинарника kubegrunt:

Создайте файлы с именем oidc-thumbprint.sh со следующим содержимым.

#!/bin/bashTHUMBPRINT=$(echo | openssl s_client -servername oidc.eks.${1}.amazonaws.com -showcerts -connect oidc.eks.${1}.amazonaws.com:443 2>&- | tac | sed -n '/-----END CERTIFICATE-----/,/-----BEGIN CERTIFICATE-----/p; /-----BEGIN CERTIFICATE-----/q' | tac | openssl x509 -fingerprint -noout | sed 's/://g' | awk -F= '{print tolower($2)}')
THUMBPRINT_JSON="{\"thumbprint\": \"${THUMBPRINT}\"}"
echo ${THUMBPRINT_JSON}

А затем сослаться на приведенный выше скрипт в ресурсе terraform, который получит отпечаток.

data "aws_region" "current" {}# Fetch OIDC provider thumbprint for root CA
data "external" "thumbprint" {
  program = ["./oidc-thumbprint.sh", data.aws_region.current.name]
}resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = concat([data.external.thumbprint.result.thumbprint], var.oidc_thumbprint_list)
  url             = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

2. Получите его вручную

На самом деле я получил его вручную, а затем добавил в свой шаблон terraform. Смотрите инструкцию как его получить:

• Прежде чем вы сможете получить отпечаток для OIDC IdP, вам необходимо установить OpenSSL cli.
• Начните с URL-адреса поставщика удостоверений OIDC (например, https://server.example.com). Этот URL-адрес доступен, если щелкнуть кластер EKS в консоли AWS, а затем добавить /.well-known/openid-configuration, чтобы сформировать URL-адрес для документа конфигурации поставщика удостоверений, например следующий: Открыть этот URL-адрес в Интернете браузере, заменив его именем сервера вашего IdP.https://server.example.com/.well-known/openid-configuration
server.example.com
• В ответе в браузере найдите «jwks_uri». Скопируйте полное доменное имя URL. Не включайте https://путь или любой другой путь после домена верхнего уровня. То, что вам нужно, может выглядеть так:
  server.example.com/sadasdasd/keys
• Используйте инструмент командной строки OpenSSL для выполнения следующей команды, которая использует пример вывода выше

openssl s_client -servername server.example.com/sadasdasd/keys -showcerts -connect server.example.com:443/sadasdasd/keysFor some people the following command will also work:openssl s_client -servername server.example.com -showcerts -connect server.example.com:443

• В командном окне прокручивайте вверх, пока не увидите сертификат. Если вы видите более одного сертификата, найдите последний отображаемый сертификат (в нижней части вывода команды). Это будет сертификат корневого центра сертификации в цепочке центров сертификации. Скопируйте сертификат (включая строки -----BEGIN CERTIFICATE-----и -----END CERTIFICATE-----) и вставьте его в текстовый файл. Затем сохраните файл под именем ca_root.crt . Затем выполните следующее:

openssl x509 -in ca_root.crt -fingerprint -noout
# the above line will output something like:
# SHA1 Fingerprint=9E:99:A4:8A:99:60:B1:49:26:BB:7F:3B:02:E2:2D:A2:B0:AB:72:80# Remove the colon characters (:) from this string to produce the final thumbprint, like this:
echo -n "9E:99:A4:8A:99:60:B1:49:26:BB:7F:3B:02:E2:2D:A2:B0:AB:72:80" | sed 's|:||g'# Final output
9E99A48A9960B14926BB7F3B02E22DA2B0AB7280

Теперь, когда вы получили отпечаток, ваш ресурс OIDC будет выглядеть так:

### OIDC config
resource "aws_iam_openid_connect_provider" "cluster" {
client_id_list = ["sts.amazonaws.com"]
thumbprint_list = ["9E99A48A9960B14926BB7F3B02E22DA2B0AB7280"]
url = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

3. Провайдер TLS [ОБНОВЛЕНО 28.08.20]

С выпуском 2.2.0 -> https://github.com/hashicorp/terraform-provider-tls/releases/tag/v2.2.0 провайдера TLS terraform теперь вы можете очень легко получить отпечаток. Смотри ниже:

data "tls_certificate" "cluster" {
  url = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}resource "aws_iam_openid_connect_provider" "cluster" {
  client_id_list = ["sts.amazonaws.com"]
  thumbprint_list = concat([data.tls_certificate.cluster.certificates.0.sha1_fingerprint], var.oidc_thumbprint_list)
  url = aws_eks_cluster.cluster.identity.0.oidc.0.issuer
}

Завершая этот раздел, я хотел бы еще раз указать, что отпечаток OIDC — это требование IAM, а не функция EKS. При настройке поставщика IAM в консоли автоматически выбирается отпечаток корневого ЦС. Этот отпечаток является хэшем обслуживающего центра сертификации. В Terraform вы должны получить его другим способом, и три варианта подробно описаны выше.

Ограничение доступа к учетным данным профиля инстанса Amazon EC2

Перед созданием фактического примера и обновлением нашей учетной записи службы нам необходимо отключить доступ к учетным данным профиля экземпляра Amazon EC2. По умолчанию контейнеры, работающие на ваших рабочих узлах, не защищены от доступа к учетным данным, которые предоставляются в профиль экземпляра рабочего узла через сервер метаданных экземпляра Amazon EC2.

Чтобы предотвратить доступ контейнеров в модулях к учетным данным, предоставленным в профиль экземпляра рабочего узла, запустите следующие iptablesкоманды на своих рабочих узлах (как root) или включите их в сценарий пользовательских данных начальной загрузки вашего экземпляра.

# commands block ALL containers from using the instance profile credentials
yum install -y iptables-services
iptables --insert FORWARD 1 --in-interface eni+ --destination 169.254.169.254/32 --jump DROP
iptables-save | tee /etc/sysconfig/iptables 
systemctl enable --now iptables

Настройте роль IAM и используйте ее для Amazon VPC CNI.

Подключаемый модуль Amazon VPC CNI для Kubernetes — это сетевой подключаемый модуль для организации сетей модулей в кластерах Amazon EKS. Плагин CNI отвечает за выделение IP-адресов VPC узлам Kubernetes и настройку необходимой сети для модулей на каждом узле. Плагину требуются разрешения IAM, предоставляемые управляемой политикой AWS AmazonEKS_CNI_Policy, для совершения вызовов API AWS от вашего имени. По умолчанию эта политика привязана к роли IAM вашего рабочего узла. Опять же, в этом случае я использую Terraform для создания роли IAM.

1. IAM предполагает ролевую политику

Создайте файл oidc_assume_role_policy.json со следующим содержимым:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "${OIDC_ARN}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${OIDC_URL}:sub": "system:serviceaccount:${NAMESPACE}:${SA_NAME}"
}
}
}
]
}

Это общая политика предполагаемых ролей, которую я использую для нескольких ролей IAM.

2. Конфигурация роли IAM

Используя terraform, мы собираемся создать роль IAM с приведенной выше политикой принятия роли, а также управляемой политикой, называемойAmazonEKS_CNI_Policy.

resource "aws_iam_role" "aws_node" {
  name = "${var.tags["ServiceType"]}-${var.tags["Environment"]}-aws-node"assume_role_policy =  templatefile("oidc_assume_role_policy.json", { OIDC_ARN = aws_iam_openid_connect_provider.cluster.arn, OIDC_URL = replace(aws_iam_openid_connect_provider.cluster.url, "https://", ""), NAMESPACE = "kube-system", SA_NAME = "aws-node" })tags = merge(
    var.tags,
    {
      "ServiceAccountName"      = "aws-node"
      "ServiceAccountNameSpace" = "kube-system"
    }
  )depends_on = [aws_iam_openid_connect_provider.cluster]
}resource "aws_iam_role_policy_attachment" "aws_node" {
  role       = aws_iam_role.aws_node.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"depends_on = [aws_iam_role.aws_node]
}

apiVersion: v1
kind: ServiceAccount
metadata:
name: aws-node
namespace: kube-system

apiVersion: v1
kind: ServiceAccount
metadata:
  name: aws-node
  namespace: kube-system
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::0123456789:role/eks-dev-aws-node

kubectl apply -f sa_aws_node.yaml

kubectl rollout restart -n kube-system daemonset.apps/aws-node

kubectl get -n kube-system daemonset.apps/aws-node --watch

kubectl exec -n kube-system aws-node-9rgzw env | grep AWS# Expected Output:
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token AWS_VPC_K8S_CNI_LOGLEVEL=DEBUG AWS_ROLE_ARN=arn:aws:iam::0123456789:role/eks-dev-aws-node

Burp Suite — это набор устройств, используемых для пентестинга и проверки безопасности. Этот учебник в основном посвящен бесплатной версии. Burp Suite может действовать как прерывающий прокси-сервер, а также перехватывать трафик между интернет-браузером и веб-сервером. Другие функции Burp Suite включают в себя сканер, паука с поддержкой приложений, злоумышленника, ретранслятор, секвенсор, компаратор, расширитель и декодер.

Функции

Ниже приведено описание возможностей Burp Suite:

• Сканер: Сканирует на наличие уязвимостей.
• Паук, учитывающий приложения: используется для пролистывания заданного экстента страниц.
• Злоумышленник : используется для выполнения атак и грубой силы на страницах адаптируемым способом.
• Повторитель : используется для контроля и перенаправления всех запросов.
• Sequencer : используется для тестирования токенов сеанса.
• Расширитель : позволяет вам легко создавать свои плагины для получения пользовательских функций.
• Компаратор и декодер: оба используются для разных целей.

Отрыгивающий паук

В Burp Suite также есть ошибка, известная как Burp Spider. Burp Spider — это программа, которая просматривает все целевые страницы, указанные в области. Перед запуском ошибки Burp необходимо настроить Burp Suite для захвата HTTP-трафика .

Что такое входное тестирование веб-приложений?

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

Интерфейс

Как и другие инструменты, Burp Suite содержит строки, строки меню и различные наборы панелей.

В приведенной ниже таблице показаны различные варианты, описанные ниже.

1. Вкладки выбора инструментов и параметров: выберите инструменты и настройки.
2. Просмотр карты сайта: показывает карту сайта.
3. Очередь запросов: показывает, когда выполняются запросы.
4. Сведения о запросе/ответе: показывает запросы и ответы от сервера.

Паукообразный поиск веб-сайта является важной функцией выполнения тестов веб-безопасности. Это помогает определить степень веб-приложения. Как упоминалось выше, в Burp Suite есть собственный паук, называемый Burp Spider, который может проникнуть на веб-сайт. В основном он включает четыре шага.

Шаги

Шаг 1: Настройте прокси

Сначала запустите Burp Suite и проверьте параметры на дополнительной вкладке « Параметры ».

IP -адрес обнаружения — это IP-адрес локального хоста , а порт — 8080 .

Кроме того, проверьте, чтобы перехват был включен. Откройте Firefox и перейдите на вкладку « Параметры ». Нажмите « Настройки », затем « Сеть» , затем « Настройки подключения » , а затем выберите « Ручная настройка прокси -сервера» .

Чтобы установить прокси, вы можете установить селектор прокси со страницы надстроек и нажать « Настройки » .

Перейдите в « Управление прокси » и включите другого посредника, завершив применимые данные.

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

Шаг 2: Получение контента

После того, как вы настроите прокси, перейдите к цели, введя URL-адрес в строке адреса. Вы можете видеть, что страница не загружается. Это происходит потому, что Burp Suite фиксирует ассоциацию.

В Burp Suite вы можете увидеть параметры запроса. Нажмите вперед, чтобы продвинуть ассоциацию. На этом этапе вы можете видеть, что страница сложена в программе.

Возвращаясь к Burp Suite, вы можете видеть, что все области заполнены.

Шаг 3: Выбор и запуск паука

Здесь выбираются объективные mutillidae . Щелкните правой кнопкой мыши цель mutillidae на карте сайта и выберите параметр « Паук отсюда ».

Когда начнется Паук, вы получите краткую информацию, как показано на прилагаемом рисунке. Это структура входа. Паук сможет сканировать на основе предоставленной информации. Вы можете пропустить этот процесс, нажав кнопку «Игнорировать форму».

Шаг 4: Манипуляции с деталями

По мере запуска ошибки дерево в ветви mutillidae заполняется. Аналогично, сделанные запросы отображаются в строке, а подробности перечислены на вкладке « Запрос ».

Перейдите к различным вкладкам и просмотрите все основные данные.

Наконец, проверьте, готов ли Паук, просмотрев вкладку Паук.

Это очень важные и начальные этапы тестирования веб-безопасности с использованием Burp Suite. Паукообразная разведка — важная часть разведки во время теста, и, выполнив ее, вы сможете лучше понять устройство целевого участка. В следующих учебных упражнениях мы применим это к различным инструментам в наборе устройств Burp Suite.

Вывод

Burp Suite можно использовать в качестве основного http-посредника для блокирования трафика для исследования и воспроизведения, сканера безопасности веб-приложений, инструмента для выполнения механизированных атак на веб-приложение, устройства для проверки всего сайта для распознавания поверхности атаки и модуль API с множеством доступных сторонних надстроек. Я надеюсь, что эта статья помогла вам узнать больше об этом замечательном инструменте для пентестинга.

Статья является переводом linuxhint.com

Использование отравления веб-кеша для проведения XSS – атаки

Возможно, самая простая уязвимость отравления веб-кэша, которую можно использовать, — это когда ввод без ключа отражается в кешируемом ответе без надлежащей очистки.

Например, рассмотрим следующий запрос и ответ:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: innocent-website.co.uk

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://innocent-website.co.uk/cms/social.png" />

Здесь значение X-Forwarded-Hostзаголовка используется для динамического создания URL-адреса изображения Open Graph, который затем отражается в ответе. Что особенно важно для отравления веб-кэша, X-Forwarded-Hostзаголовок часто не имеет ключа. В этом примере кеш потенциально может быть отравлен ответом, содержащим простую полезную нагрузку XSS:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://a."><script>alert(1)</script>"/cms/social.png" />

Если бы этот ответ был кэширован, все пользователи, получившие доступ, получили /en?region=ukбы эту полезную нагрузку XSS. Этот пример просто вызывает появление предупреждения в браузере жертвы, но реальная атака потенциально может украсть пароли и взломать учетные записи пользователей.

Использование отравления веб-кеша для использования небезопасной обработки импорта ресурсов

Некоторые веб-сайты используют заголовки без ключа для динамического создания URL-адресов для импорта ресурсов, таких как внешние файлы JavaScript. В этом случае, если злоумышленник изменит значение соответствующего заголовка на домен, который он контролирует, он потенциально может манипулировать URL-адресом, чтобы вместо этого указать на свой собственный вредоносный файл JavaScript.

Если ответ, содержащий этот вредоносный URL-адрес, кэшируется, файл JavaScript злоумышленника будет импортирован и выполнен в сеансе браузера любого пользователя, чей запрос имеет соответствующий ключ кэша.

GET / HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: evil-user.net
User-Agent: Mozilla/5.0 Firefox/57.0

HTTP/1.1 200 OK
<script src="https://evil-user.net/static/analytics.js"></script>

Использование отравления веб-кэша для использования уязвимостей в обработке файлов cookie

Файлы cookie часто используются для динамического создания контента в ответе. Типичным примером может быть файл cookie, указывающий предпочитаемый пользователем язык, который затем используется для загрузки соответствующей версии страницы:

GET /blog/post.php?mobile=1 HTTP/1.1
Host: innocent-website.com
User-Agent: Mozilla/5.0 Firefox/57.0
Cookie: language=pl;
Connection: close

В этом примере запрашивается польская версия сообщения в блоге. Обратите внимание, что информация о том, какую языковую версию использовать, содержится только в Cookieзаголовке. Предположим, что ключ кеша содержит строку запроса и Hostзаголовок, но не сам Cookieзаголовок. В этом случае, если ответ на этот запрос кэшируется, все последующие пользователи, пытавшиеся получить доступ к этому сообщению в блоге, также получат польскую версию, независимо от того, какой язык они фактически выбрали.

Эта ошибочная обработка файлов cookie кешем также может быть использована с использованием методов отравления веб-кэша. Однако на практике этот вектор встречается относительно редко по сравнению с отравлением кэша на основе заголовков. Когда существуют уязвимости, связанные с отравлением кеша на основе файлов cookie, они, как правило, быстро выявляются и устраняются, потому что законные пользователи случайно отравили кеш.

Использование нескольких заголовков для эксплуатации уязвимостей отравления веб-кэша

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

Например, предположим, что для веб-сайта требуется безопасная связь с использованием HTTPS. Чтобы обеспечить это, если получен запрос, использующий другой протокол, веб-сайт динамически генерирует перенаправление на себя, которое использует HTTPS:

GET /random HTTP/1.1
Host: innocent-site.com
X-Forwarded-Proto: http

HTTP/1.1 301 moved permanently
Location: https://innocent-site.com/random

Само по себе такое поведение не обязательно уязвимо. Однако, объединив это с тем, что мы узнали ранее об уязвимостях в динамически генерируемых URL-адресах, злоумышленник потенциально может использовать это поведение для создания кэшируемого ответа, который перенаправляет пользователей на вредоносный URL-адрес.

Использование ответов, раскрывающих слишком много информации

Иногда веб-сайты делают себя более уязвимыми для отравления веб-кэша, выдавая слишком много информации о себе и своем поведении.

Директивы управления кэшем

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

Одним из таких примеров является ситуация, когда ответы содержат информацию о том, как часто кеш очищается или сколько лет текущему кэшированному ответу:

HTTP/1.1 200 OK
Via: 1.1 varnish-v4
Age: 174
Cache-Control: public, max-age=1800

Хотя это не ведет напрямую к отравлению веб-кэша, оно избавляет потенциального злоумышленника от некоторых ручных усилий, потому что он точно знает, когда отправлять свою полезную нагрузку, чтобы обеспечить ее кеширование.

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

Изменить заголовок

Элементарный способ, которым Varyчасто используется заголовок, также может помочь злоумышленникам. Заголовок Varyопределяет список дополнительных заголовков, которые следует рассматривать как часть ключа кэша, даже если они обычно не имеют ключей. Он обычно используется, чтобы указать, что User-Agentзаголовок имеет ключ, например, чтобы, если мобильная версия веб-сайта была кэширована, она не была ошибочно предоставлена ​​немобильным пользователям.

Эта информация также может быть использована для построения многоэтапной атаки, нацеленной на определенное подмножество пользователей. Например, если злоумышленник знает, что User-Agentзаголовок является частью ключа кэша, то, сначала определив пользовательский агент предполагаемых жертв, он может адаптировать атаку таким образом, чтобы затронуты были только пользователи с этим пользовательским агентом. В качестве альтернативы они могли бы выяснить, какой пользовательский агент чаще всего использовался для доступа к сайту, и адаптировать атаку таким образом, чтобы затронуть максимальное количество пользователей.

Использование отравления веб-кэша для использования уязвимостей на основе DOM

Как обсуждалось ранее, если веб-сайт небезопасно использует заголовки без ключа для импорта файлов, злоумышленник потенциально может использовать это для импорта вредоносного файла. Однако это относится не только к файлам JavaScript.

Многие веб-сайты используют JavaScript для получения и обработки дополнительных данных из серверной части. Если скрипт обрабатывает данные с сервера небезопасным образом, это потенциально может привести ко всем видам уязвимостей на основе DOM.

Например, злоумышленник может отравить кеш ответом, который импортирует файл JSON, содержащий следующую полезную нагрузку:

{"someProperty" : "<svg onload=alert(1)>"}

Если затем веб-сайт передает значение этого свойства в приемник, поддерживающий динамическое выполнение кода, полезная нагрузка будет выполняться в контексте сеанса браузера жертвы.

Если вы используете отравление веб-кэша, чтобы заставить веб-сайт загружать вредоносные данные JSON с вашего сервера, вам может потребоваться предоставить веб-сайту доступ к JSON с помощью CORS :

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *

{
"malicious json" : "malicious json"
}

Цепочка уязвимостей отравления веб-кэша

Как мы видели ранее, иногда злоумышленник может получить вредоносный ответ только путем создания запроса с использованием нескольких заголовков. Но то же самое верно и для различных типов атак. Отравление веб-кэша иногда требует от злоумышленника объединения нескольких техник, которые мы обсуждали. Объединяя вместе различные уязвимости, часто можно выявить дополнительные уровни уязвимости, которые изначально были неиспользуемыми.

Статья является переводом portswigger.net

Что такое отравление веб-кэша?

Отравление веб-кэша — это продвинутый метод, с помощью которого злоумышленник использует поведение веб-сервера и кеша, чтобы вредоносный HTTP-ответ доставлялся другим пользователям.

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

Отравленный веб-кеш потенциально может быть разрушительным средством распространения множества различных атак, использования уязвимостей, таких как XSS , внедрение JavaScript, открытое перенаправление и т. д.

Исследование отравления веб-кэша

Этот метод был впервые популяризирован в нашей исследовательской статье 2018 года «Практическое отравление веб-кэша» и получил дальнейшее развитие в 2020 году во второй исследовательской статье «Запутывание веб-кэша: новые пути к отравлению». Если вам интересно подробное описание того, как мы обнаружили и использовали эти уязвимости в реальных условиях, полные записи доступны на нашей странице исследования.

Как работает веб-кеш?

Чтобы понять, как возникают уязвимости, связанные с отравлением веб-кеша, важно иметь общее представление о том, как работает веб-кэш.

Если бы серверу приходилось отправлять новый ответ на каждый отдельный HTTP-запрос отдельно, это, вероятно, привело бы к перегрузке сервера, что привело бы к проблемам с задержкой и плохому взаимодействию с пользователем, особенно в периоды занятости. Кэширование — это, прежде всего, средство уменьшения таких проблем.

Кэш находится между сервером и пользователем, где он сохраняет (кэширует) ответы на определенные запросы, обычно в течение фиксированного периода времени. Если другой пользователь затем отправляет эквивалентный запрос, кеш просто передает копию кэшированного ответа непосредственно пользователю, без какого-либо взаимодействия с серверной частью. Это значительно снижает нагрузку на сервер, уменьшая количество повторяющихся запросов, которые ему приходится обрабатывать.

Ключи кэша

Когда кеш получает HTTP-запрос, он сначала должен определить, есть ли кешированный ответ, который он может обслужить напрямую, или он должен перенаправить запрос для обработки внутренним сервером. Кэши идентифицируют эквивалентные запросы, сравнивая предопределенное подмножество компонентов запроса, известных под общим названием «ключ кэша». Как правило, это будет содержать строку запроса и Hostзаголовок. Компоненты запроса, не включенные в ключ кэша, называются «неключевыми».

Если ключ кэша входящего запроса совпадает с ключом предыдущего запроса, то кэш считает их эквивалентными. В результате будет предоставлена ​​копия кэшированного ответа, созданного для исходного запроса. Это относится ко всем последующим запросам с совпадающим ключом кэша, пока срок действия кэшированного ответа не истечет.

Важно отметить, что другие компоненты запроса полностью игнорируются кешем. Позже мы более подробно рассмотрим влияние такого поведения.

Каковы последствия атаки с отравлением веб-кэша?

Воздействие отравления веб-кэша сильно зависит от двух ключевых факторов:

• Что именно злоумышленник может успешно закэшировать?
  Поскольку зараженный кеш — это скорее средство распространения, чем отдельная атака, воздействие отравления веб-кэша неразрывно связано с тем, насколько опасна внедренная полезная нагрузка. Как и в случае большинства видов атак, отравление веб-кеша также можно использовать в сочетании с другими атаками, чтобы еще больше усилить потенциальное воздействие.
• Объем трафика на затронутой странице
  . Отравленный ответ будет обслуживаться только пользователями, которые посещают затронутую страницу, пока кеш отравлен. В результате влияние может варьироваться от несуществующего до огромного в зависимости от того, популярна ли страница или нет. Например, если злоумышленнику удалось отравить кешированный ответ на главной странице крупного веб-сайта, атака может затронуть тысячи пользователей без какого-либо последующего взаимодействия со стороны злоумышленника.

Обратите внимание, что продолжительность записи в кэше не обязательно влияет на влияние отравления веб-кеша. Атака обычно может быть запрограммирована таким образом, чтобы повторно отравлять кеш на неопределенный срок.

Выявление и оценка неключевых входных данных

Любая атака с отравлением веб-кэша основана на манипулировании входными данными без ключей, такими как заголовки. Веб-кэши игнорируют входные данные без ключа при принятии решения о предоставлении пользователю кэшированного ответа. Такое поведение означает, что вы можете использовать их для внедрения своей полезной нагрузки и получения «отравленного» ответа, который, если он кэшируется, будет обслуживаться для всех пользователей, чьи запросы имеют соответствующий ключ кэша. Таким образом, первым шагом при построении атаки с отравлением веб-кэша является идентификация входных данных без ключей, которые поддерживаются сервером.

Вы можете идентифицировать входные данные без ключа вручную, добавляя случайные входные данные к запросам и наблюдая, влияют ли они на ответ. Это может быть очевидно, например, прямое отражение ввода в ответе или запуск совершенно другого ответа. Однако иногда эффекты более тонкие, и для их понимания требуется немного детективной работы. Вы можете использовать такие инструменты, как Burp Comparer, для сравнения отклика с введенным вводом и без него, но это по-прежнему требует значительного объема ручных усилий.

Парам Майнер

К счастью, вы можете автоматизировать процесс определения входных данных без ключа, добавив расширение Param Miner в Burp из магазина BApp. Чтобы использовать Param Miner, вы просто щелкаете правой кнопкой мыши запрос, который хотите исследовать, и нажимаете «Угадать заголовки». Затем Param Miner запускается в фоновом режиме, отправляя запросы, содержащие различные входные данные из обширного встроенного списка заголовков. Если запрос, содержащий один из введенных им входных данных, влияет на ответ, Param Miner регистрирует это в Burp либо на панели «Проблемы», если вы используете Burp Suite Professional , либо на вкладке «Вывод» расширения (« Расширитель” > “Расширения” > “Param Miner” > “Вывод”

Например, на следующем снимке экрана Param Miner обнаружил заголовок без ключа X-Forwarded-Hostна главной странице веб-сайта:

Предостережение. При тестировании неключевых входных данных на действующем веб-сайте существует риск непреднамеренного срабатывания кеша для обслуживания сгенерированных вами ответов реальным пользователям. Поэтому важно убедиться, что все ваши запросы имеют уникальный ключ кеша, чтобы они были доставлены только вам. Для этого можно вручную добавлять блокировщик кеша (например, уникальный параметр) в строку запроса каждый раз, когда вы делаете запрос. В качестве альтернативы, если вы используете Param Miner, есть варианты автоматического добавления очистки кеша к каждому запросу.

Получение вредоносного ответа от внутреннего сервера

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

Получить ответ в кэше

Манипулирование входными данными для получения вредоносного ответа — это полдела, но оно не принесет многого, если вы не можете кэшировать ответ, что иногда может быть сложно.

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

Использование уязвимостей отравления веб-кэша

Этот базовый процесс можно использовать для обнаружения и использования различных уязвимостей, связанных с отравлением веб-кэша.

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

В следующих разделах мы рассмотрим некоторые из наиболее распространенных примеров обоих этих сценариев. Мы также предоставили ряд интерактивных лабораторий, чтобы вы могли увидеть некоторые из этих уязвимостей в действии и попрактиковаться в их эксплуатации.

Как предотвратить отравление веб-кэша уязвимостями

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

Даже если вам нужно использовать кэширование, ограничение его чисто статическими ответами также эффективно, при условии, что вы достаточно осторожны с тем, что вы классифицируете как «статическое». Например, убедитесь, что злоумышленник не сможет обманом заставить внутренний сервер получить свою вредоносную версию статического ресурса вместо подлинной.

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

В частности, в контексте отравления веб-кэша это означает не только принятие решения о том, оставить ли кеширование включенным по умолчанию, но и просмотр того, например, какие заголовки поддерживаются вашей CDN. Некоторые из рассмотренных выше уязвимостей, связанных с отравлением веб-кэша, обнаруживаются, потому что злоумышленник может манипулировать серией неясных заголовков запросов, многие из которых совершенно не нужны для функциональности веб-сайта. Опять же, вы можете подвергать себя такого рода атакам, не осознавая этого, просто потому, что вы внедрили какую-то технологию, которая по умолчанию поддерживает эти неключевые входные данные. Если заголовок не нужен для работы сайта, то его следует отключить.

Вы также должны принять следующие меры предосторожности при реализации кэширования:

• Если вы планируете исключить что-то из ключа кеша по соображениям производительности, вместо этого перепишите запрос.
• Не принимайте жирные GETзапросы. Имейте в виду, что некоторые сторонние технологии могут разрешать это по умолчанию.
• Закрывайте уязвимости на стороне клиента, даже если они кажутся неиспользуемыми. Некоторые из этих уязвимостей на самом деле могут быть использованы из-за непредсказуемых особенностей поведения вашего кеша. Это может быть вопросом времени, когда кто-то найдет причуду, будь то кеш или что-то еще, что делает эту уязвимость пригодной для эксплуатации.

Статья является переводом portswigger.net