Automação Old School
No mundo de TI nos bate papos informais é comum ouvirmos de sysadmins Old School frases como essas: “No meu tempo eu fazia shellzinho e tava resolvido”, “Eu automatizo tudo com Perl”, “Faço tudo em Bash” se você ouvir coisas assim desconfie na hora!!! Acho que até eu mesmo já devo ter dito isso em algum momento no passado antes da iluminação, essas frases não estão erradas, elas cumprem o que prometem e o trabalho é realmente feito, mas a pergunta que precisa ser feita é, essa é a melhor formar de fazer isso hoje em dia?
Testando um shellzinho
Vamos criar uma VM e fazer um teste com um “shellzinho”, você pode utilizar o post Conhecendo o Vagrant como modelo para essa atividade.
1# Automação Old School
2
3$shellzinho = <<-SCRIPT
4echo Chamndo o meuu shellzinho...
5echo `date` >> /home/vagrant/Shellzinho
6echo nameserver 8.8.8.8 >>/etc/resolv.conf
7apt-get update
8apt-get install vim
9apt-get install wget
10apt-get install nginx-full -y
11SCRIPT
12
13
14Vagrant.configure("2") do |config|
15
16 hostname = "Infra-as-Code-Old-School"
17 config.vm.box = "minimal/trusty64"
18 config.vm.hostname = hostname
19 config.vm.box_url = "minimal/trusty64"
20 config.vm.boot_timeout = 3600
21 config.vm.network "private_network", type: "dhcp"
22
23 config.vm.provider :virtualbox do |v|
24 v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
25 v.customize ["modifyvm", :id, "--memory", 512]
26 v.customize ["modifyvm", :id, "--name", hostname ]
27 end
28
29 config.vm.provision "shell", inline: $shellzinho
30
31
32end
Vamos desligar e ligar a máquina cinco vezes
1 vagrant up
2 vagrant halt
Verificando as execuções vimos que funcionou certo? Com toda certeza o shellzinho sempre funciona, mas a que custo?
1$ vagrant ssh
2
3$ cat /home/vagrant/Shellzinho /etc/resolv.conf
4
5Sat Aug 24 01:08:20 PDT 2019
6Sat Aug 24 01:09:29 PDT 2019
7Sat Aug 24 01:11:10 PDT 2019
8Sat Aug 24 01:11:53 PDT 2019
9Sat Aug 24 01:12:55 PDT 2019
10Sat Aug 24 04:11:55 PDT 2019
11# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
12# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
13nameserver 10.0.2.3
14nameserver 8.8.8.8
15nameserver 8.8.8.8
16nameserver 8.8.8.8
17nameserver 8.8.8.8
18nameserver 8.8.8.8
19nameserver 8.8.8.8
Funcionou certo? Funcionou até bem demais fez a mesma coisa seis vezes, vamos entender a razão disso.
Idempotência
O nosso shellzinho fez a mesma coisa mais de uma vez, por quê? A resposta é simples porque ele não respeita uma regra chamada Idempotência. Idem… o quê?!! I-d-e-m-p-o-t-ê-n-c-i-a, tá lembrado da Tia Maria da 5a série, no 3o bimestre na aula de matemática, quando ela explicava sobre operações de conjuntos e da propriedade de idempotência onde: A ∩ A = A?
Para refrescar a sua memória, abaixo temos a fórmula da idempotência e sua definição.
f(f(x)) = f(x)
Idempotência é uma propriedade matemática que algumas operações possuem, essa propriedade permite que uma determinada função seja aplicadas várias vezes sem que o valor do resultado se altere após a primeira execução, veja a definição na Wikipedia. Para o mundo da automação idempotência garante que uma tarefa seja executada apenas uma vez mesmo que ela seja chamada inúmeras vezes.
Conclusão
O shellzinho Old School ajuda? Sem dúvida ajuda. O shellzinho está errado? Definitivamente não, mas ele não garante a idempotência de suas ações, para garantir, você mesmo tem que criar os mecanismos e certificar que essas garantias funcionem. A idempotência é um paradigma fundamental utilizado pelas ferramentas de gestão de configuração tais como: Puppet, Chef, Ansible e outras, essas ferramentas possuem mecanismos internos que garantem a execução de apenas uma vez das tarefas programadas e isso facilita muito a vida de um Sysadmin, agora que conhecemos esse conceito podemos partir para brincadeiras mais legais!! Aguardem o próximo post, até lá!!!
Convido você a ver os outros posts do blog Infra-as-Code.
Nossos contatos são:
Email – [email protected]
Twitter - @infraascodebr
|