dry run
Dry run — may refer to: Dry run (testing), a testing process Dry run (terrorism), a test to examine how security will react to an attempted terrorist attack without carrying out the actual act Places in the United States Dry Run, Ohio, a census designated… … Wikipedia
Dry Run — ist der Name mehrerer Orte in den Vereinigten Staaten: Dry Run (Maryland) Dry Run (Ohio) Dry Run (Pennsylvania) Dry Run (West Virginia) Diese Seite ist eine Begriffsklärung zur Unterscheidung mehrerer mit demselben Wort bezeichneter Begriffe … Deutsch Wikipedia
Dry Run — may refer to: * Dry Run (testing), a testing process * Dry Run, West Virginia * Dry Run, Ohio … Wikipedia
Dry Run — Dry Run, OH U.S. Census Designated Place in Ohio Population (2000): 6553 Housing Units (2000): 2118 Land area (2000): 4.754303 sq. miles (12.313589 sq. km) Water area (2000): 0.000000 sq. miles (0.000000 sq. km) Total area (2000): 4.754303 sq.… … StarDict’s U.S. Gazetteer Places
Dry Run, OH — U.S. Census Designated Place in Ohio Population (2000): 6553 Housing Units (2000): 2118 Land area (2000): 4.754303 sq. miles (12.313589 sq. km) Water area (2000): 0.000000 sq. miles (0.000000 sq. km) Total area (2000): 4.754303 sq. miles… … StarDict’s U.S. Gazetteer Places
dry run — dry runs N COUNT: oft N for n If you have a dry run, you practise something to make sure that you are ready to do it properly. The competition is planned as a dry run for the World Cup finals … English dictionary
dry run — n an event that is a practice for a more important event ▪ Both the parties are treating the local elections as a dry run … Dictionary of contemporary English
dry run — A dry run is a full rehearsal or trial exercise of something to see how it will work before it is launched … The small dictionary of idiomes
dry run — dry′ run′ n. 1) a rehearsal 2) mil practice in firing arms without using live ammunition • Etymology: 1940–45, amer. dry′ run , adj … From formal English to slang
dry run — • dry run • dummy run an experiment or trial of a machine or project under realistic (but not real) conditions … Idioms and examples
dry run — dry run, adj. 1. a rehearsal or practice exercise. 2. Mil. practice in firing arms without using live ammunition. [1940 45, Amer.] * * * … Universalium
DRY RUN
• испытание макета аппаратуры • предстартовая подготовка без подачи топлива к двигателю • предстартовая подготовка ЖРД без подачи топлива к двигателю • сухая заправка • сухое моделирование • сухой прогон. смотреть
DRY RUN
1) работа на холостом ходу 2) холостой пробег; холостой ход (рабочего органа) 3) отработка (УП) на холостых ходах 4) работа без смазки; работа без СОЖ 5) пробный прогон (напр. УП). смотреть
DRY RUN
1) работа на холостом ходу 2) холостой пробег; холостой ход (рабочего органа) 3) отработка (УП) на холостых ходах 4) работа без смазки; работа без СОЖ 5) пробный прогон (напр. УП). смотреть
DRY RUN
dry run n AmE vulg sl She had a natural distaste for a dry run Половой акт с применением презерватива вызывал у нее естественное отвращение
DRY RUN
n AmE vulg sl She had a natural distaste for a dry run — Половой акт с применением презерватива вызывал у нее естественное отвращение
На пути к тестируемому инфраструктурному коду
Программный код часто содержит баги, и это нормально. Мой первый скрипт был для раскладывания скриншотов по датам и названию игр. Тестировал его я, разумеется, руками, поэтому заняло это несколько дней. Знай я на тот момент хоть один фреймворк тестирования, весь процесс отладки занял бы считанные часы.
Сейчас я пишу больше инфраструктурного кода: утилиты бэкапов, скрипты мониторинга, Kubernetes-манифесты, Ansible-плейбуки, Terraform-модули, и, чуть не забыл, CI/CD. Иногда он бывает простым, иногда странным, но чаще — нетестируемым. Инфраструктурный код — это код в мешке: пока не запустишь — не узнаешь, что случится. В среднем я делаю 10—20 запусков пайплайна в Jenkins, чтобы довести код CI до рабочего состояния.
Ах да, не протестированный инфраструктурный код может быть просто опасным. В лучшем случае он может запуститься во всех окружениях и упасть во время сборки в production, в среднем — стереть бэкап или выдавать ложные показания в графане, в худшем — выдавать неконсистентный бэкап на протяжении полугода, пока вам не понадобится его восстановить.
Kipo and the Age of Wonderbeasts, 2017
Сейчас расскажу, как можно все эти беды свести к минимуму.
Настройте линтеры
Mypy, когда я запустил его на скрипте без аннотаций типов.
Допустим, у нас есть Kubernetes-манифест, Terraform-модуль, а также Python-скрипт для отправки уведомлений в Slack, и запускаются они из GitLab CI. Здесь всё может пойти не так, и под «всё» я имею ввиду «что угодно». Собственно, часть проблем из списка «что угодно» отлавливается на этапе статического анализа.
Для Kubernetes-кода можно написать свой скрипт, который читает YAML-файлы и проверяет как минимум наличие необходимых ключей в структуре. Вот, к примеру, валидация меток внутри Deployment:
Можно заменить его на уже существующий инструмент, однако он, возможно,не умеет разбирать новомодные CRD. Но можно скомбинировать оба подхода и получить валидатор структур для выявления плохих практик или явных ошибок — например, отсутствия привязки к SHA-сумме образа в поде.
Terraform-код проверяется тремя способами. Во-первых, при помощи стандартных инструментов Terraform — команд fmt, plan, validate. Во-вторых, существует популярный инструмент tflint, имеющий встроенные базовые проверки стиля кода, но с возможностью расширения своими правилами или плагинами сообщества.
В-третьих, tflint опирается на набор библиотек для работы с HashiCorp Configuration Language (HCL), их же использует и сам Terraform. HCL описывает общий синтаксис .tf/.hcl-файлов, а также алгоритм многоэтапной обработки конфигурации. Первый этап состоит из проверки синтаксиса и парсинга, следующие — из разбора и подстановки переменных из соседних файлов конфигурации, вызовов функций, обработки шаблонов и другого. HCL SDK состоит из обёртки hclsimple (высокоуровневое API для преобразования файлов в Go-структуры), из gohcl и hclparse (инструменты для разбора структуры HCL-текста), а также из утилиты hcldec, которая просто преобразовывает HCL в JSON, что полезно для парсинга не из Go, а из других языков. По своему опыту могу сказать, что работать с HCL SDK не так просто, но такова цена столь мощного языка.
Для проверки стиля и синтаксиса Python-скрипт для Slack можно пропускать через Pylint, можно также добавить mypy для остроты или дополнительные проверки к pylint по вкусу.
Получается, что статический анализ позволяет проверять ошибки в коде и конфигурации, и подходит для всего, за исключением, пожалуй, Groovy/Jenkins Pipeline (попробуйте его распарсить, я посмотрю) или конфигов со сложным синтаксисом (привет, Nginx!).
Его минус заключается в том, что это просто статический анализ, больше подходящий для выявления стилистических ошибок — логические или фактические ошибки из коробки с его помощью обнаружить не получится.
Внедрите режим проверки
Возможно, вы уже встречали нечто вроде режима проверки в DevOps-утилитах, действия которых могут быть разрушительными. Например, у инструмента бэкапов Restic при вызове команды forget (удаление резервных копий) есть параметр —dry-run , при котором утилита не удаляет ничего, а просто выводит информацию о том, какие снимки данных были бы удалены согласно указанным политикам очистки. Ansible имеет параметр —check , при котором его модули ничего не меняют на хостах, Terraform — plan , по которому можно понять, что произойдёт при apply.
А что если в инфраструктурный код встроить такой режим, при котором система будет действовать в формате «только для чтения»? Или пайплайн, скажем, будет только доставать объекты из S3, модифицировать их согласно бизнес-логике, но не перезаписывать обратно? В теории можно получить безопасный пайплайн и убедиться в том, что как минимум часть кода работает.
Пишите скрипты отката, настройте версионирование
Я, когда надо откатывать пайплайн.
Этот вариант предлагает смотреть на каждый пайплайн как на своеобразную миграцию, с которой можно откатиться. Пайплайн развёртывает новую версию конфигов Nginx или DNS? Напишите скрипт или конфиг-бэкап, с которым можно моментально откатиться в случае ошибки.
Пример: модуль Ansible template при перезаписи файла main.conf будет копировать оригинал в main.conf.old.
Этого достаточно для ручного отката. Но лучше спланировать CI/CD таким образом, что при миграции БД перед запуском приложения вы напишете также скрипт отката на предыдущую версию, который будет автоматически запускаться в случае ошибки пайплайна. Это может потребовать переработки инструментария, например, уйти в сторону Immutable Infrastructure на основе Packer, однако эффект будет уникальный — вы сможете запускать пайплайны, не боясь ошибиться.
Изучите SDK используемого вами инструментария
Некоторые инструменты обладают вшитыми возможностями для тестирования. У Ansible есть фреймворк Molecule для тестирования ролей и проверки последствий их выполнения в Docker-контейнерах, и не только. Puppet SDK тоже имеет свою среду для тестирования. Helm-чарты вроде как тоже можно прогонять через юнит-тесты Helm.
Когда пришла таска на Молекулу.
Правда, тут есть два «но». Первое — вам, скорее всего, придётся переписывать код того же плейбука Ansible, чтобы его можно было бы протестировать. Переходить на TDD необязательно, но можно, главное — разделить код на тестируемые части. Йей, рефакторинг!
Реакция моего напарника (привет, Илья!) на слова «Давай перепишем!»
Но есть системы, для которых нельзя написать юнит-тесты. Например, CI/CD. Как быть в этом случае? По возможности, надо ориентироваться на инструменты с поддержкой юнит-тестирования. Если такой возможности нет, то одно из следующих решений вам наверняка подойдёт.
Вынесите CI в тестируемый код
В CI, как уже говорилось, с тестируемостью всё сложно, как и в любой другой расширяемой и кастомизируемой системе. В чём же сложность? Представьте, что у вас есть утилита с GUI, и вы написали несколько плагинов, которые цепляются «хуками» к основной системе и отрисовывают свои формы и панели на основном GUI. Такие компоненты будут нетестируемыми без запуска основной утилиты. А если утилита не предусматривает проверок компонентов by design — вы в ловушке.
То же самое с CI. CI/CD — это расширяемая правилами и скриптами утилита с внутренним интерфейсом, с которым вы активно взаимодействуете и без которого протестировать пайплайн невозможно. Ну, в первоначальном виде.
Но что если поменять правила игры и вынести логику CI в отдельную утилиту, которая легче поддавалась бы тестированию? Скажем, есть пайплайн, который через плагин Jenkins достаёт токен из Vault и с его помощью выкачивает артефакт из репозитория сборок через curl. В этом случае можно вынести логику выгрузки сборки в отдельный инструмент на каком-нибудь Python, покрыть его тестами с моками и ассертами, в общем, сделать из баша конфетку!
Я, когда начал разносить код CI по библиотекам и инструментам.
И кстати, разделите код и конфигурацию
Одним из правил хорошего тона в программировании является принцип «Разделяй и властвуй». Другими словами, полезно разделять код на доменные уровни, на компоненты. Но некоторые забывают, что ещё можно разделять «код» и «не код»! То есть выделять из общей кодовой базы тесты и конфигурацию. И хотя некоторые (Rust, Go) языки пропагандируют «сближение» тестов и кода, проводить decoupling кода и конфигурации можно в любом языке программирования. Помимо того, что это позволяет легче управлять приложением в разных окружениях (dev/stage/prod/…), вы сможете настраивать приложение без выполнения пересборки проекта, что, впрочем, очевидно.
Как это относится к теме статьи? Приведу пример из жизни «Домклика». Мы активно используем Jenkins и Vault, и случается, что кто-то ошибается в пути и поле key/value-записи, или же забывает выдать нужные политики для approle. Инженеры — тоже люди, которые, бывает, ошибаются в конфигурации пайплайна. И вынос конфигурации из кода даёт возможность провести дополнительные проверки, в данном случае — перед запуском пайплайна можно убедиться, что такое поле вообще есть в Vault и оно доступно из такой approle.
Короче говоря, деритесь с кодом, режьте его, легаси складывайте в морозилку, конфигурацию тестируйте.
Кодья драка!
На самом деле это переосмысление моего личного опыта — что бы я поменял в тех или иных проектах, будь у меня такая возможность. Возможно, что-то из перечисленного вам пригодится, а может, станет для вас отправной точкой для собственных открытий.
Ну или вдруг кадры-иллюстрации из «Кипо и Эра Чудесных Зверей» сподвигнут вас посмотреть сей замечательный сериал, я не знаю.
Where does the phrase "dry run" come from?
I’ve heard the phrase «dry run» being used with the meaning of rehearsal, experiment or test exercise in various contexts. For example:
They did a dry run of the demonstration before showing it to the CEO.
Practice with a dry run. Organise a dress rehearsal within two weeks of the wedding to ensure.
A dry run of the software release will be executed to ensure that the release plan is correct and clear to everybody.
However, wet run would not make sense in any of these contexts. So, why «dry»? Where does «dry run» come from?
6 Answers 6
According to World Wide Words, it originates from firemen doing speed competitions without carrying water.
The term run, more fully fire run, has for at least the past century been used by local fire departments in the USA for a call-out to the site of a fire. It was once common for fire departments or volunteer hose companies to give exhibitions of their prowess at carnivals or similar events. [. ] These competitions had fairly standard rules, of which several examples appear in the press of this period, such as in the Olean Democrat of 2 August 1888: “Not less than fifteen or more than seventeen men to each company. Dry run, standing start, each team to be allowed one trial; cart to carry 350 feet of hose in 50 foot lengths . ”.
These reports show that a dry run in the jargon of the fire service at this period was one that didn’t involve the use of water, as opposed to a wet run that did. In some competitions there was a specific class for the latter, one of which was reported in the Salem Daily News for 6 July 1896: “The wet run was made by the Fulton hook and ladder company and the Deluge hose company. The run was made east in Main street to Fawcett’s store where the ladders were raised to the top of the building. The hose company attached [its] hose to a fire plug and ascending the ladder gave a fine exhibition.”
It’s clear that the idea of a dry run being a rehearsal would very readily follow from the jargon usage, though it first appears in print only much later.
In addition to the dried out riverbed, a dry run can also be a dry enclosure for poultry to run in. But for practice meaning, Etymonline.com says "Dry run is from 1940s" and there’s plenty of US military examples of a practice without ammunition during WWII.
Military: firing practice without ammunition
American Speech defined the term during WWII. "Glossary of Army Slang", Vol. 16, No. 3, Oct., 1941:
DRY RUN. To practice; a dress rehearsal.
‘DRY RUN (to practice; a dress rehearsal).’ I never heard it used as a verb, or to mean a dress rehearsal. Originally a semi-official term for practice firing without ammunition, it is slang in other senses, such as a mail-call at which one receives no mail.
From a 1932 Coast Artillery Journal:
Later we had a short practice with the Navy; a so-called "dry run," which proved not so dry.
From a 1932 The Military Engineer description of 1918:
The French had designed a trestle for a bridge over the river and one over the canal and delivered them to us in trucks ready framed for erecting. Many dry-run erections were made on dark nights until the structures could be erected in .
Also some army test flights, including this non-military 1934 test flight in Multiple lens aerial cameras in mapping:
Climb to altitude and if the area is near at hand study ground and map flight lines, while climbing. 5. Reaching altitude, make a trial or "dry" run. This enables the pilot to find his drift and the photographer to find the time between .
(There are later test flights in in 1938’s The principles and practice of surveying and 1941’s Photogrammetric engineering and remote sensing.)
Unsubstantiated theories
Here’s a theory with not much to back it up. The banks of dried riverbeds, dry runs, were useful as tactical cover for infantry. This 1914 Infantry Journal says:
In framing problems, take as few liberties with the landscape as possible. It borders on the ridiculous to state in a maneuver problem that a dry run is an unfordable river or that a hill is a marsh.
It’s a stretch, but were dry river beds often used for infantry practice maneuvers? Did this lead to dry run becoming a practice without ammunition?
As per the etymology for "dry run", I wonder if the roots to its artillery past aren’t stronger than what is given on the site. When muzzle-loading cannon is fired, the bore is swabbed out with a wet sponge on a pole so that the embers from the shot that was fired, do not prematurely ignite the gunpowder that is being loaded for the next shot. Of course, if the exercise is just a drill, there would be no need for a wet sponge. A dry one would be used. Hence, "dry run"?
I should add that when a firing range on a military base is ready to start shooting, the Range Commander asks for permission to "go wet". A flag is raised and the shooting starts.
I can’t find any evidence for this, but there’s definitely a strong military connection.
Firemen’s races: practice run without water
However, the fireman theory is also good. The military use is practice firing without ammunition. The firemen’s use is a practice run without water.
During firemen’s races, each part of putting out a fire became its own event: a dry run: "running out the hose" over a distance and connecting to a hydrant; a wet test: "throwing out water" with given pressure over a distance; a coupling contest: attaching hose to the hydrant; a ladder climbing contest.
The 1894 The New York clipper annual . containing theatrical, musical and sporting chronologies . includes three instances of dry run in firemen’s races, for example:
dry run, 200yds. to hydrant, attaching, unreeling 350ft. of regulation hose, breaking coupling and putting on pipe, each three full turns, cast 515lb, stripped, pipe 24[?] long, 51/2lb, carried by pipeman, who started with team.
So they run with the hose and attach to a hydrant, but in each, no mention is made of turning on the water. The same publication details other races describing a certain steam pressure and water pressure.
A 1910 The Harvester World details a similar Fire Department Contest, with a similar Dry Run event, with other events: Ladder Climbing Contest, Coupling Contest, and a Wet Test involving "throwing water".
The 1916 Tacoma: its history and its builders; a half century of activity
Eagle Hose Company of Old Tacoma won the "wet test" in 38 1/2. seconds. The "wet test" consisted of running 660 feet, connecting with a hydrant and throwing water. The "dry test" was won by a Vancouver, BC, company in 4 1/2 seconds. A squabble arose in the firemen’s contests over the right of Struve, one of the Seattle firemen to participate, it being charged that he was a professional runner, which in fact he was. Some two years before he had run a race in Tacoma with Halstead, and had carried a 50-pound sack of flour on his shoulders as a handicap.
The British Fire Prevention Committee’s 1907 Red Books tabulates the results of dry and wet tests. It also talks of a "for position of hydrants and run of hose, see Fig. 7." and several uses of "the hose was run out in [a direct line/the same direction]". So run appears to be the technical term for laying out hose, and perhaps why the US races are generally either "dry run" or "wet test" (in addition ladder climb or coupling contest) — each part of the drill is separated out.