DevOps Engineer
Configuration management зачем оно надо?
Раньше к серверам относились к любимым домашним питомцам, но время идет. Теперь подход в том, что это “стадо”. Надо менять подходы к управлению серверами. Если мы говорим что инфраструктура это код, то за нас уже давно все придумано. Есть множество наработанных практик:
Вот возьмем Bash.Xорошая вещь же? Но проблема в том, что бы на нем написать что-то не ломающееся и поддерживаемое надо быть найти высоко качественных специалистов. CM системы, тот же ansible, позволяют получать средней ломучести код. Что в свою очередь позволяет “удешевить” используемых спциалистов или ускорить их появление.
CM, и ansible в частности, это не про то, что будет меньше кода, это про разбиение предметной области на “слои”/абстракции и работы с ними.
Вот рассмотрим банальный пример. выбрать все файлы в текущей директории и скопировать в другое место
for i in * ; do cp $i /some/path/$i.bak ; done
for i in * ; do cp "$i" "/some/path/$i.bak" ; done
find . -type f -exec mv -v {} dst/{}.bak \;
\n
.touch x
mv x "$(printf "foo\nbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir
Это всего лишь один из примеров, а таких нюансов тысячи. Вот вы знали, что в bash есть hash конструкция? Есть то такая конструкция есть, но как с ней жить дальше?
#!/bin/bash
function print_animals() {
local local_animals
eval "declare -A local_animals="${1#*=}
for sound in "${!local_animals[@]}" ; do
echo "$sound - ${local_animals[$sound]}"
done
}
declare -A animals
animals["moo"]="cow"
animals["woof"]="dog"
print_animals "$(declare -p animals)"
Configuration management и иже с ними позволяют понизить порог входа. Порог входа в отдельные части системы, задачи. Т.е. не надо держать в штате только гуру, достаточно пару кто видит задачу в целом, а потом дробит ее на примитивы. С bash же, все должны понимать коварство bash.
Make configuration management not bash