Ubuntu 24.04 VPS için Ansible playbook yazma rehberi

Yapılacaklar

Ansible'ın kurulu olduğu bir denetim makinesi ile üzerinde stok imaj dışında hiçbir şey bulunmayan bir veya daha fazla yeni Ubuntu 24.04 VPS kurulacaktır. İşlemin sonunda sunucularınızı adlandıran bir envanter dosyasına, kimlik doğrulamanın uçtan uca çalıştığını kanıtlayan geçici bir ping komutuna ve yeni VPS denetim listesinin tamamını kod olarak çalıştıran bir playbook'a sahip olunacaktır: SSH anahtarınızla bir dağıtım kullanıcısı, güvenliği güçlendirilmiş sshd, fail2ban, unattended upgrades ve diğer tüm bağlantıları reddetmeden önce OpenSSH'e izin veren bir güvenlik duvarı. Yapılandırma tek bir sunucuya veya yirmi sunucuya uygulanabilir. İkinci kez çalıştırıldığında hiçbir değişiklik yapılmaz. Amaç budur.

On beş yıllık VPS hazırlama deneyiminden sonra görülen durum açıktır: Herkes ilk beş sunucuyu elle kurar, ardından altıncı sunucuda bir hafta sonunu kaybeder; çünkü ilk beş sunucuda ne yaptığını kimse hatırlamaz. Bu kılavuz, birden fazla Linux sunucusunu yönetme konusunu daha ayrıntılı ele alır. Aynı apt install komutunu üç terminalde yazdığınızı fark ettiğiniz gün bu kılavuza başvurun.

Ansible'in gerçekte ne olduğu, tek paragrafta

Ansible aracısızdır. Yönettiği sunuculara kurulacak bir daemon yoktur: kontrol makinesi normal SSH üzerinden bağlanır, küçük bir Python modülünü hedefe kopyalar, modülü çalıştırır, yazdırdığı JSON verisini okur ve modülü siler. Bir hedefin ihtiyaç duyduğu tek şey python3 değeridir; bu değer her standart Ubuntu imajında zaten bulunur. Önemli olan sözcük idempotent ifadesidir ve anlamı açıktır: bir görev, eylemi değil bir durumu tanımlar. Bir paket için state: present, "bunun kurulu olduğundan emin ol" anlamına gelir; "yükleyiciyi çalıştır" anlamına gelmez. Durum zaten sağlanmışsa Ansible hiçbir değişiklik yapmaz ve sonucu ok olarak bildirir; changed olarak bildirmez. Ürünün tamamı bu özelliktir; bir playbook'un yeniden çalıştırılmasını güvenli kılan da budur ve güvenli yeniden çalıştırmalar, kabuk betiğini altyapıya dönüştürür.

Ön koşullar ve baştan bilinmesi gereken sorunlar

• Bir kontrol makinesi: dizüstü bilgisayarınız veya küçük bir VPS. Ubuntu 24.04 varsayılmaktadır; Homebrew üzerinden pipx kurulduktan sonra macOS da aynı şekilde çalışır.
• KVM üzerinde Ubuntu 24.04 çalıştıran ve root olarak erişilebilen bir veya daha fazla hedef VPS. Bu makinelere hiçbir şey kurulmaz.
• Her hedef için SSH anahtarı kimlik doğrulaması. Ansible, kimlik doğrulaması açısından ssh komutunuzla tamamen aynıdır; ssh root@host parola isterse Ansible başarısız olur.
• Ubuntu 24.04 üzerinde pip install ansible, error: externally-managed-environment ile sonlanır. Bu bir bozulma değil, dağıtımın kasıtlı politikasıdır. pipx kullanılmalıdır.
• YAML boşluk kullanımına duyarlıdır. Girintinin yanlış olması mapping values are not allowed in this context üretir ve herhangi bir yerdeki sekme karakteri işlemi başarısız kılar.
• Playbook sshd'yi güvenli hale getirirken her hedefte çalışan bir SSH oturumunu açık tutun. Kurtarılmasına yardımcı olduğum her erişim kilitlenmesinde, son oturum "temiz ortamdan test etmek" amacıyla kapatılmıştı.

Adım 1: Ansible'ı pip ile değil, pipx ile denetim makinesine kurma

Klasik ilk tepki pip3 install ansible olur. Gerçekten temiz bir 24.04 imajında bu işlem bir adım önce, Command 'pip3' not found, but can be installed with: sudo apt install python3-pip nedeniyle başarısız olur. pip kurulumu da yalnızca asıl engele ulaşmanızı sağlar:

pip3 install ansible

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

Ubuntu 24.04, sistem Python'ını harici olarak yönetilen bir ortam olarak işaretler (PEP 668). Bu nedenle pip, aynı dosyalar üzerinde apt ile çakışamaz. --break-system-packages komutunu kullanmayın. Bayrağın adı ne yaptığını açıkça belirtir. Doğru çözüm pipx kullanmaktır. pipx, Ansible için yalıtılmış bir virtualenv oluşturur ve ikili dosyaları PATH üzerine yerleştirir:

sudo apt update && sudo apt install -y pipx
pipx ensurepath
pipx install --include-deps ansible

PATH değişikliğinin etkin olması için pipx ensurepath işleminden sonra yeni bir kabuk açın. --include-deps yalnızca biçimsel bir seçenek değildir. ansible paketi kendi konsol betiklerini sağlamaz; ansible, ansible-playbook ve diğerleri ansible-core bağımlılığının giriş noktalarıdır. Bu nedenle bayrak kullanılmadığında pipx kurulumu No apps associated with package ansible or its dependencies ile reddeder. Ayrıca yalnızca ansible-core değil, ansible paketini kurun. Tam paket, topluluk koleksiyonlarını içerir. Bu playbook, bu koleksiyonlardan ikisindeki modülleri kullanır (ansible.posix ve community.general).

ansible --version

Doğru sonuç ansible [core 2.19.x] benzeri bir satırla başlar ve çalıştığı Python sürümünü belirtir. Bu işlemde kullanılacak tüm işlevler için güncel bir core sürümü uygundur. ansible: command not found çıktısı, ~/.local/bin ifadesinin henüz PATH üzerinde olmadığını gösterir. Yeni bir kabuk açın veya source ~/.bashrc çalıştırın.

Kurulumun tamamı budur. Hedeflerde hiçbir işlem yapılmaz.

Adım 2: Her hedefe SSH anahtarıyla erişim

ssh-keygen -t ed25519 -C "ansible control"
ssh-copy-id root@10.0.0.10
ssh-copy-id root@10.0.0.20

Ardından her ana bilgisayar için bir kez doğrulayın:

ssh root@10.0.0.10 true && echo ok

Bu tek satır iki işi yapar: anahtar kimlik doğrulamasının parola olmadan çalıştığını doğrular ve ana bilgisayar anahtarını known_hosts içine kaydeder. Bunu şimdi yapın. Aksi takdirde Ansible, kaydedilmemiş bir ana bilgisayar anahtarını çalışmanın ortasında gizlenen etkileşimli bir istem olarak gösterir; bu da tam olarak işlemin takıldığı izlenimini verir.

3. Adım: envanter; önce INI, büyüdüğünde YAML

Envanter, Ansible'ın erişebileceği makineleri listeleyen bir metin dosyasıdır. Yeni bir proje dizininde inventory.ini dosyasını oluşturun:

[vps]
web1 ansible_host=10.0.0.10
web2 ansible_host=10.0.0.20

[vps:vars]
ansible_user=root

web1 seçtiğiniz bir takma addır. Çıktıda görünen ad budur ve --limit web1 ile hedeflediğiniz addır. ansible_host gerçek adrestir. [vps] bir gruptur ve [vps:vars] bu gruptaki her ana bilgisayar için değişkenleri ayarlar; ansible_user ise Ansible'ın oturum açacağı kullanıcıdır. Bunun yanına bir ansible.cfg ekleyin; böylece -i değerini tekrar yazmanız gerekmez:

[defaults]
inventory = inventory.ini

Ansible, ansible.cfg dosyasını geçerli dizinden okur. Aynı envanteri YAML biçiminde inventory.yml adıyla kaydedip ansible.cfg seçeneğini bu ada yönlendirin. Ana bilgisayarların her biri birden fazla değişken taşıdığında bu yöntemi tercih edeceksiniz:

vps:
  hosts:
    web1:
      ansible_host: 10.0.0.10
    web2:
      ansible_host: 10.0.0.20
  vars:
    ansible_user: root

İkisi de eşdeğerdir. İki sunucuda INI biçimini hızlıca incelemek daha kolaydır; yirmi sunucuda YAML daha iyi ölçeklenir. Birini seçin ve bu konuyu artık düşünmeyin.

4. Ad-hoc komutları: her şeyi doğrulayan yeşil pong

ansible all -m ping

Bu işlem ICMP kullanmaz. ping modülü tam bir prova gerçekleştirir: SSH ile oturum açar, modülü kopyalar, hedefte Python çalıştırır ve temizleme işlemi yapar. Doğru sonuç yeşildir ve her ana bilgisayar için bir blok görüntülenir:

web1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Yeşil SUCCESS; kimlik doğrulamanın, Python yorumlayıcısının ve aktarımın çalıştığını gösterir. Bu durumda playbook da çalışır. Kırmızı UNREACHABLE!, herhangi bir modül çalıştırılmadan önce aktarımın başarısız olduğu anlamına gelir. Hata durumları aşağıdaki bölümde ilgili tam dize ve düzeltme açıklanır. Bilinmesi gereken iki ad-hoc komutu daha:

ansible all -a "uptime"
ansible all -m apt -a "update_cache=true upgrade=dist" --become

Ad-hoc komutları tek seferlik işlemler ve kontroller için kullanılır. İki kez çalıştırılacak her işlem playbook içine alınmalıdır.

5. Adım: ilk playbook, yeni VPS kontrol listesinin kod olarak uygulanması

Bu, yeni bir sunucuda ilk 10 dakika içinde elle yapılacak işlemlerin tamamıdır. Bunu site.yml olarak kaydedin:

---
- name: Baseline a fresh Ubuntu VPS
  hosts: vps
  become: true

  vars:
    deploy_user: deploy
    deploy_pubkey: "{{ lookup('file', '~/.ssh/id_ed25519.pub') }}"
    baseline_packages:
      - fail2ban
      - unattended-upgrades
      - ufw
    baseline_services:
      - fail2ban
      - unattended-upgrades

  tasks:
    - name: Create the deploy user
      ansible.builtin.user:
        name: "{{ deploy_user }}"
        groups: sudo
        append: true
        shell: /bin/bash

    - name: Install the deploy user's SSH key
      ansible.posix.authorized_key:
        user: "{{ deploy_user }}"
        key: "{{ deploy_pubkey }}"

    - name: Passwordless sudo for the deploy user
      ansible.builtin.copy:
        dest: /etc/sudoers.d/deploy
        content: "{{ deploy_user }} ALL=(ALL) NOPASSWD:ALL\n"
        mode: "0440"
        validate: /usr/sbin/visudo -cf %s

    - name: Install baseline packages
      ansible.builtin.apt:
        name: "{{ baseline_packages }}"
        state: present
        update_cache: true

    - name: Enable and start baseline services
      ansible.builtin.service:
        name: "{{ item }}"
        state: started
        enabled: true
      loop: "{{ baseline_services }}"

    - name: Harden sshd with a drop-in
      ansible.builtin.copy:
        dest: /etc/ssh/sshd_config.d/00-hardening.conf
        content: |
          PasswordAuthentication no
          KbdInteractiveAuthentication no
          PermitRootLogin prohibit-password
          X11Forwarding no
        mode: "0644"
        validate: /usr/sbin/sshd -t -f %s
      notify: Restart ssh

    - name: Allow OpenSSH through ufw
      community.general.ufw:
        rule: allow
        name: OpenSSH

    - name: Enable ufw with default deny
      community.general.ufw:
        state: enabled
        policy: deny

  handlers:
    - name: Restart ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

Kopyalamak yerine anlaşılması gereken satırlar:

Değişkenler vars: altında tanımlanır ve "{{ deploy_user }}" ile kullanılır. Bir değer süslü ayraçla başlıyorsa ifadenin tamamını tırnak içine alın; aksi halde YAML ayrıştırıcısı ifadeyi yanlış yorumlar. lookup('file', ...), çalışma zamanında public key değerini control makinesinden okur. Böylece playbook içinde anahtar materyali bulunmaz.

Döngü. loop: "{{ baseline_services }}", hizmet görevini her öğe için bir kez çalıştırır ve çıktıda her öğeyi ayrı satırda gösterir. apt görevinin bunun yerine tüm paket listesini tek seferde aldığını unutmayın. Paketler için tek bir apt işlemi daha hızlıdır ve tercih edilen yöntemdir. Döngüler, gerçekten tek seferde yalnızca bir öğe üzerinde işlem yapan modüller içindir.

Handler, özümsenmesi gereken kavramdır. notify: Restart ssh, "ssh'yi şimdi yeniden başlat" anlamına gelmez. Handler'ı kuyruğa alır. Handler, play'in sonunda bir kez çalışır ve yalnızca bildirim gönderen görev gerçekten changed bildirdiyse çalıştırılır. Playbook'u yarın yeniden çalıştırın: drop-in dosyası zaten doğrudur, copy görevi ok bildirir ve sshd yeniden başlatılmaz. validate: satırı, tetikleyici için güvenlik kontrolüdür. sshd eski yapılandırmayı değiştirmeden önce dosyayı denetler. Böylece yazım hatası daemon'u bozmak yerine görevin başarısız olmasına neden olur.

PermitRootLogin prohibit-password, no değil, kasıtlı olarak kullanılır. Bu playbook root hesabıyla ve bir key kullanarak oturum açar. prohibit-password, sizin oturumunuzu açık tutarken root hesabıyla password login işlemlerini devre dışı bırakır. Deploy user doğrulandıktan sonra (ssh deploy@10.0.0.10 sudo true, düz adres; çünkü web1 yalnızca Ansible'ın bildiği bir alias'tır), inventory içindeki ansible_user=deploy değerini değiştirin ve sonraki çalıştırmada bunu no olarak sıkılaştırın. Erişiminizi kaybetmenize neden olmayacak bir sırayla güvenliği güçlendirin.

00- ön eki önemlidir. sshd, çoğu anahtar sözcük için ayrıştırdığı ilk oluşumu kullanır. Ubuntu'nun sshd_config dosyası, kendi gövdesinden önce sözlüksel sırayla sshd_config.d/*.conf dosyasını içerir. Ubuntu 24.04 cloud image'ları bu dizinde zaten bir 60-cloudimg-settings.conf dosyası sağlar. cloud-init üzerinden password login işlemlerini etkinleştiren sağlayıcılar ise 50-cloud-init.conf dosyasını PasswordAuthentication yes ile ekler. Dosyamıza 00-hardening.conf adını vermek, dosyanın ilk sırada gelmesini ve her ikisine de üstün gelmesini sağlar.

Görevlerin sırası firewall güvenliğini sağlar. Allow OpenSSH, deny policy ile Enable ufw işleminden önce çalışır. Ansible görevleri listelenen sıraya kesin olarak uyar. Bu nedenle duvar etkinleşmeden önce açıklık oluşur. fail2ban'ın burada yararlı olması için ek yapılandırma gerekmez. Ubuntu varsayılanları sshd'yi doğrudan izler. Jail'lerin gerçekte ne yaptığı ve hangi ayarların değiştirileceği, Ubuntu 24.04 üzerinde fail2ban kılavuzu içinde ele alınır.

Adım 6: --check ile deneme çalıştırması yapın, ardından gerçek çalıştırmayı başlatın

ansible-playbook site.yml --check

Denetim modu bağlantı kurar ve ne yapacağını hesaplar, ancak hiçbir değişiklik yapmaz. Alttaki PLAY RECAP bölümünde yer alan changed= sayısını okuyun. Bu sayı, her ana bilgisayarı değiştirecek görevlerin sayısıdır. Önemli bir sınırlama vardır: Daha sonraki bir görev önceki bir görevin yaptığı değişikliklere bağlı olduğunda denetim modu yapısal olarak sınırlıdır. Ubuntu'nun standart server image sürümü ufw ile önceden geldiğinden bu playbook deneme çalıştırmasında sorunsuz çalışır. Ancak ufw'nin bulunmadığı minimal bir image kullanılırsa ufw görevleri denetim modunda başarısız olur. Bunun nedeni, denetim modunun paketi gerçekten kurmaması ve modülün çağırabileceği bir bileşen bulunmamasıdır. Bu durum, playbook'taki bir hata değil, deneme çalıştırmalarının bir sınırlamasıdır. Plan doğru görünüyorsa:

ansible-playbook site.yml

Her görev, her ana bilgisayar için bir satır yazdırır. changed sarı, ok yeşil renktedir. Özet şu şekilde olmalıdır:

PLAY RECAP *********************************************************************
web1 : ok=10  changed=9  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
web2 : ok=10  changed=9  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

On ok, gerçeklerin toplanması, sekiz görev ve handler görevinden oluşur. changed değerinizin benimkinden bir veya iki farklı olması normaldir. Ubuntu'nun standart image sürümü ufw ve unattended-upgrades ile önceden gelir. Ayrıca fail2ban, apt tarafından kurulur kurulmaz kendisini başlatır. Bu nedenle bir görev ilk çalıştırmada meşru olarak ok bildirebilir. Bu, görevin bildirdiği durumun zaten mevcut olduğu anlamına gelir. Sıfır olması gereken sayılar unreachable ve failed değerleridir. become: true hakkında bir not: root olarak bağlandığınız sürece bu yalnızca bir formalitedir. Ancak ansible_user değerini deploy olarak değiştirdiğiniz anda sudo gerçekten devreye girer. Bu playbook'un kurduğu NOPASSWD sudoers dosyası, -K ifadesinin komut satırınızda görünmesini önleyen bileşendir. Bu dosya olmadan aşağıda açıklanan Missing sudo password ile karşılaşırsınız.

Adım 7: iki kez çalıştırma ve idempotence davranışı

Aynı komutu hemen tekrar çalıştırın:

web1 : ok=9  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

changed=0 ve ok birer azaldı; çünkü bildirim gönderilmemiş işleyici hiç çalışmadı. Hiçbir şey yeniden kurulmadı, sshd yeniden başlatılmadı ve ufw üzerinde işlem yapılmadı. Playbook'u bir provisioner kadar denetim aracı yapan özellik budur: gelecek ay envantere web3 ekleyip yeniden çalıştırın; yeni sunucu oluşturulur, mevcut sunucular doğrulanır. Dokunmadığınız bir sunucudaki sıfır olmayan changed değeri drift olduğunu gösterir. Ayrıca, playbook'ta bulunması gereken bir ayarın birisi tarafından elle değiştirildiğini belirtir.

Bu noktadan sonra aynı yaklaşım genişletilebilir. Yazılması gereken bir sonraki playbook, aynı VPS üzerinde bir WireGuard VPN kurmalı ve ufw kuralını SSH'nin yalnızca tünel üzerinden yanıt vereceği şekilde sıkılaştırmalıdır. Bundan sonra her uygulama sunucusuna Docker ve Compose kuran bir playbook yazılabilir. site.yml üç ekranı aşmaya başladığında bunu rollere ayırın, ancak bundan önce ayırmayın.

Hatalı çalışma durumları ve görülecek iletiler

UNREACHABLE with Permission denied.

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: root@10.0.0.10: Permission denied (publickey).",
    "unreachable": true
}

SSH aktarımı, herhangi bir modül çalışmadan önce başarısız oldu: ansible_user yanlış, anahtar bu makineye hiç kopyalanmadı veya yanlış anahtar sunuluyor. Düz ssh root@10.0.0.10 komutuyla yeniden deneyin, ardından hangi anahtarların sunulduğunu görmek için ssh -v çalıştırın. Parolalı SSH çalışıyor ancak Ansible çalışmıyorsa ssh-copy-id seçeneğini atlamışsınızdır.

Eksik sudo parolası.

web1 | FAILED! => {
    "msg": "Missing sudo password"
}

become: true ayarlandı, root olmayan bir kullanıcıyla bağlanıldı ve bu kullanıcının sudo için parolaya ihtiyacı var. Komut satırına -K (--ask-become-pass) ekleyin veya kullanıcıya NOPASSWD sudoers girdisi verin. Playbook'un, kullanıcıya geçmeden önce deploy için böyle bir girdi yüklemesinin nedeni budur.

error: externally-managed-environment. Ubuntu 24.04 sistem Python'u üzerinde pip çalıştırıldı. Bu konu 1. adımda ele alınmıştır: pip değil pipx kullanılmalı ve --break-system-packages kullanılmamalıdır.

mapping values are not allowed in this context.

ERROR! Syntax Error while loading YAML.
  mapping values are not allowed in this context

Neredeyse her zaman neden girintidir: bir anahtar yanlış düzeydedir veya iki noktadan sonra boşluk eksiktir. Bildirilen satır numarası hatanın bulunduğu yeri değil, yakınını gösterir; üstündeki satırı da kontrol edin. Bunun benzeri olan found character '\t' that cannot start any token, bir sekme karakterinin eklendiği anlamına gelir; YAML sekme karakterlerine izin vermez. Her çalıştırmadan önce ansible-playbook site.yml --syntax-check komutunu alışkanlık haline getirin ve düzenleyicinizi YAML için iki boşluklu girintiye ayarlayın.

/usr/bin/python3: not found. Standart Ubuntu 24.04 imajlarında nadirdir, minimal veya netboot imajlarında yaygındır: hedefte Python bulunmadığı için modül çalıştırılamaz. raw modülüyle Python'u önyükleyin. Uzak tarafta hiçbir gereksinimi olmayan tek modül budur: ansible all -m raw -a "apt-get update && apt-get install -y python3" --become. Ardından playbook'u yeniden çalıştırın.

FAQ

Ansible'ı yönettiği sunuculara yüklemek gerekir mi?

Hayır. Ansible aracısız çalışır: denetim makinesi küçük Python modüllerini SSH üzerinden gönderir, çalıştırır ve kaldırır. Hedefte yalnızca python3 ve SSH erişimi bulunmalıdır; stok Ubuntu imajlarında her ikisi de zaten bulunur. Bu kılavuzdaki tek yükleme işlemi denetim makinenizde gerçekleştirilir.

Ansible neden "Permission denied (publickey)" hatası veriyor?

UNREACHABLE! bloğunun Permission denied (publickey) ile birlikte kullanılması, Ansible herhangi bir işlem çalıştırmadan önce SSH kimlik doğrulamasının başarısız olduğunu gösterir. Envanterdeki ansible_user değerinin gerçekten yapılandırdığınız hesapla eşleştiğini, bu makineye ssh-copy-id çalıştırdığınızı ve düz ssh user@host komutunun parola istemeden oturum açtığını denetleyin. Düz ssh komutunu düzelten işlem Ansible'ı da düzeltir; çünkü ikisi aynı aktarım mekanizmasını kullanır.

Ansible'da idempotent ne anlama gelir?

Bir görev, gerçekleştirilecek bir eylem yerine istenen durumu bildirir: "bu paket mevcut", "bu satır bu dosyada bulunuyor". Durum zaten sağlanıyorsa Ansible hiçbir işlem yapmaz ve ok yerine changed bildirir. Bu nedenle bir playbook ikinci kez çalıştırıldığında changed=0 gösterilir; yeniden çalıştırma, riskli bir yeniden yükleme değil, güvenli bir denetimdir.

Ansible'ı Ubuntu 24.04 üzerine yüklemek için pip mi, pipx mi kullanılmalı?

pipx kullanılmalıdır. Ubuntu 24.04, sistem Python ortamını harici olarak yönetilen bir ortam olarak işaretler; bu nedenle pip install ansible tasarım gereği error: externally-managed-environment ile başarısız olur. pipx install --include-deps ansible, Ansible'ı yalıtılmış bir virtualenv içine yerleştirir ve ansible, ansible-playbook ile diğer bileşenleri PATH üzerinde düzgün şekilde kullanılabilir hale getirir.

ansible ve ansible-core paketleri arasındaki fark nedir?

ansible-core, yalnızca ansible.builtin modüllerini içeren altyapıdır. ansible paketi, çekirdek bileşenleri topluluk tarafından seçilerek düzenlenmiş koleksiyonlarla birlikte sunar. Bunlar arasında bu kılavuzda kullanılan ansible.posix (authorized_key modülü) ve community.general (ufw modülü) bulunur. Tam paketle başlanmalıdır; yalnızca bir gerekçe bulunduğunda core ve elle seçilmiş koleksiyonlarla daha küçük bir kuruluma geçilmelidir.