Administrare automată de servere cu Ansible

Am un sistem de a configura un server web pentru testări (staging, dev etc). Până acum a fost ok, configuram unul-două servere pe an, nu aveam nici o problemă.

Știam de unelte din zona Ansible/Chef/Terraform/etc, dar niciodată nu am avut răbdarea necesară pentru a aprofunda. Până recent, când am zis că Ansible este alesul [1] și m-am apucat de treabă.

Am avut nevoie de două zile pentru a asimila (suficient) noțiunile Ansible și de a pune la punct absolut TOT ce înseamnă:

  • instalare de pachete (apt install....)
  • instalare PHP (7.3 7.4 8.0 8.1), composer, wp-cli și extensiile folosite de mine în PHP
  • instalare MariaDB
  • hardening (via)
  • administrare cron, chei ssh
  • configurare site-uri
  • backup automat

De la instanțierea droplet-ului pe DigitalOcean până când am toată jucăria gata durează ~15-20 minute iar absolut TOT este 100% automatizat. Practic toată atenția acordată de mine este să fac cele cinci clickuri corect în DO (deși… tind să cred că pot automatiza și asta :grin: )

Părerea generală este că, în ciuda documentației dubioase/confuze pe alocuri, merită din plin un astfel de sistem, mai ales dacă ai nevoie frecvent de setarea rapidă a unui mediu de test (și nu ții neapărat să fie în container).

Voi ce folosiți pentru automatizare?


  1. știu că X e mai bun decât ce am ales eu, dar dacă alegeam X, atunci Y era și mai bun :smiley: ↩︎

5 Likes

Ansible ftw!

Îl folosesc pentru provizioane servere, deploy (ansistrano e role-ul pe care îl folosesc. E echivalentul lui Capistrano) și backup automat. Totul în combinație cu gitlab.

Pratic, la un nou proiect operațiunile manuale sunt creat repo, inclus template-ul de .gitlab-ci.yml, creat fișier config ansible, pornit serverul (do or whatever). Apoi provizionarea se rulează din interfata gitlab. La pus pe master se face build, rulează teste și se face deploy. Pentru backup folosesc scheduled jobs tot din gitlab.

Recomand să-ți faci o imagine de docker pe un alt repo al tău cu joburile pe care le folosești la majoritatea proiectelor și sa rulezi playbook-urile pe acea imagine.

La vechiul job era folosit și pentru scaling - erau anumite proiecte care nu foloseau auto scaling și scalarea se făcea semi-manual cu ajutorul gitlab și ansible. Rulaj un job cu nr de mașini dorite și that’s it

2 Likes

Terraform pentru creare/management de resurse

Cloud init, cat mai mult posibil pentru initializare, minimum provisioning

Ansible pull, pt chestiile mai de finete care nu le poate cloud-init sau le face prost

Sa nu cazi in capcana de a abuza de remote-exec si local-exec in terraform!
Si sa nu incerci sa configurezi servicii cu terraform, chiar daca exista providers/modules

Go full GitOps, chiar daca la inceput e putin mai dificil si pare peste mana.
Future you will thank you for that.

2 Likes

Kubernetes cu helm charts, o data ce ai helm charts-ul configurat si setat totul e automat. (pentru o intreaga aplicatie se face un asa numit umbrella chart care contine mai mult chart-uri)
Restul de automatizare pana la build-ul imaginii de docker pentru fiecare serviciu e facut in CI/CD.

Nu am folosit servere private de 3 ani. Se poate configura crearea cluster-ului in AWS/GCP cu terraform (ca sa iti aleaga ce instante sa fie, retelele, load balancing-ul, strategia de scaling), dar asta e munca de devops sau SRE care stie ce face, nu de dev.

1 Like

Esti in urma man! OpenFaaS is the next k8s! :smiley:

Nu se preteaza serverless la backend-urile pe Java. (cel putin nu inca, dar nu cred ca multi o sa aibe curajul sa treaca pe Spring Native/Quarkus…)

Si la mine se foloseste Ansible in combinatie cu ceva scripturi de python.
Se provizioneaza elemente de retea (core network) virtuale :slight_smile:

Nu fac eu asta, ci colegii dev ops.

1 Like

Nu puteau sa treaca 3 ani sa nu devina o tehnologie “obsolete”

1 Like

Păi, numa AWS Lambda are 7 ani.
3 ani imi pare suficient

Am folosit Puppet mai demult acum folosim Ansible, care e tata lor.

1 Like