Lev Goncharov

DevOps Engineer

View My GitHub Profile

Make configuration management not bash

English version

Configuration management зачем оно надо?

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

Вот возьмем Bash.Xорошая вещь же? Но проблема в том, что бы на нем написать что-то не ломающееся и поддерживаемое надо быть найти высоко качественных специалистов. CM системы, тот же ansible, позволяют получать средней ломучести код. Что в свою очередь позволяет “удешевить” используемых спциалистов или ускорить их появление.

CM, и ansible в частности, это не про то, что будет меньше кода, это про разбиение предметной области на “слои”/абстракции и работы с ними.

Bash

Вот рассмотрим банальный пример. выбрать все файлы в текущей директории и скопировать в другое место

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 \;
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)"

Conclusion

Configuration management и иже с ними позволяют понизить порог входа. Порог входа в отдельные части системы, задачи. Т.е. не надо держать в штате только гуру, достаточно пару кто видит задачу в целом, а потом дробит ее на примитивы. С bash же, все должны понимать коварство bash.

Make configuration management not bash