Giriş
Yaml1 yazması kolay bir format olsada küçük bir hata yapıldığında, farketmesi çok uzun zamanlar alabiliyor. Bunda en büyük etken, .yml dosyalarının girinitiler(indentation) ile çalışmasıdır. Ansible ile uğraştıysanız ve modüllere hakimseniz bunu kullanmak yazdığınız Playbook’lar ile bunu tecrübe etmişsinizdir Bu yazıda, bende bu sıkıntıyı nasıl minimuma indirip standarda uygun playbook’lar nasıl yazılır onu anlatacağım.
ansible-lint sizin yazdığınız Playbook’larda YAML ve Ansible formatının nerelerinde hata olduğunu size bildiren mekanizmadır. Karşılaştırma yaparsak Python’daki PEP8 standartının, Ansible karşılığı denilebilir.
Kurulum
Kurulum gayet basit
|
1 |
pip install ansible-lint |
Kullanım
Diyelim elimizde /var/www nin altındaki dosyalardan 4 haftadan eski 1 Megabyte’tan eski olan dosyaları gösteren ve yum paket reposundaki programları üst versiyona geçiren bir playbook olsun.2
|
1 2 3 4 5 6 7 8 9 10 11 12 |
--- # Ansible find module - hosts: all gather_facts: yes sudo: Yes tasks: - name: find files that older than 4w find: paths="/var/www/" age="4w" size="1m" recurse=yes register: result - debug: var=result - name: YUM UPGRADE action: yum name=* state=latest |
Kaydedilen dosyayı test edelim.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
ansible-lint test.yml [ANSIBLE0008] deprecated sudo feature find.yml:2 {'sudo': True} [ANSIBLE0011] All tasks should be named find.yml:9 Task/Handler: debug var=result [ANSIBLE0010] Package installs should not use latest find.yml:10 Task/Handler: YUM UPGRADE |
Gördüğünüz gibi dosyadaki satırlarda göre nerede yanlışlar olduğunu söylüyor. Düzeltmeside pek zor olmasa gerek.
Yapı nasıl çalışıyor
İşi biraz daha sistematik incelersek yapının pek fazla karmaşık olmadığını görebiliriz.
ansible-lint -L parametresi ile çalıştırdığımızda
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
➜ nwpwr@ubuntux ~/ansible-plays git:(master) ✗ ansible-lint -L ANSIBLE0002: Trailing whitespace There should not be any trailing whitespace ANSIBLE0004: Git checkouts must contain explicit version All version control checkouts must point to an explicit commit or tag, not just "latest" ANSIBLE0005: Mercurial checkouts must contain explicit revision All version control checkouts must point to an explicit commit or tag, not just "latest" ANSIBLE0006: Using command rather than module Executing a command when there is an Ansible module is generally a bad idea ANSIBLE0007: Using command rather than an argument to e.g. file Executing a command when there is are arguments to modules is generally a bad idea ANSIBLE0008: Deprecated sudo Instead of sudo/sudo_user, use become/become_user. ANSIBLE0009: Octal file permissions must contain leading zero Numeric file permissions without leading zero can behavein unexpected ways. See http://docs.ansible.com/ansible/file_module.html ANSIBLE0010: Package installs should not use latest Package installs should use state=present with or without a version ANSIBLE0011: All tasks should be named All tasks should have a distinct name for readability and for --start-at-task to work ANSIBLE0012: Commands should not change things if nothing needs doing Commands should either read information (and thus set changed_when) or not do something if it has already been done (using creates/removes) or only do it if another check has a particular result (when) ANSIBLE0013: Use shell only when shell functionality is required Shell should only be used when piping, redirecting or chaining commands (and Ansible would be preferred for some of those!) ANSIBLE0014: Environment variables don't work as part of command Environment variables should be passed to shell or command through environment argument ANSIBLE0015: Using bare variables is deprecated Using bare variables is deprecated. Update yourplaybooks so that the environment value uses the full variablesyntax ("{{your_variable}}"). |
Kod bloğunda görüldüğü gibi kuralların listelenmiş bir şekli var. Github’da bulunan repodaki kodları incelerseniz yapının içeriğinin, Regular Expression ağırlıklı olduğunu göreceksiniz.
Son olarak ansible-lint, tam bir debugger manası ile çalışmayıp sadece syntax yapısını ölçen bir yapısı olduğunu söyleyebilirim. Yani bu sizin ansiblenizin kesin çalışacağı anlamına gelmiyor yani sonuç odaklı değil, usül ve yöntem odaklı bir çözüm.
Umarım işinize yarar.
Daha fazlası için:
Eğer Emacs kullanıyorsanız, girintileri daha güzel görebileceğiniz şekilde ayarlamalar yapıp üstüne birde hata yakalama işleminin nasıl olduğunu anlatan bir blog yazısının, sizin için de faydanıza olacağını düşünyorum.
- https://blog.chmouel.com/2016/09/07/dealing-with-yaml-in-emacs/
- Highlight Indentation
- (Girintileri daha iyi görmenize yardımcı olur python kodlarkende çok güzel olabilecek bir paket)
- aj-toggle-fold
- Gereksiz kısımları açma kapama(fold unfold?) yapabileceğiniz bir tool.
- Flycheck-mode
- Çok fazla özelliği bulunmakta bakmanızda fayda var.
- Smart Shift
- Toplu olarak yazıları kaydımanıza yarayacak bir eklenti ben C-x TAB kullanmayı tercih ediyorum.
- Highlight Indentation