mcgrof.kdevops_vagrant

kdevops_vagrant

kdevops_vagrant to rola Ansible, która wdraża wspólny plik Vagrant z społeczności do Twojego projektu. Ta rola Ansible kopiuje plik Vagrantfile do katalogu przestrzeni nazw projektu i może opcjonalnie uruchomić Vagrant za Ciebie.

Celem tej roli Ansible jest umożliwienie łatwego dzielenia się tym samym konfigurowalnym plikiem Vagrant między projektami oraz zapewnienie miejsca dla Vagrantfile, aby umożliwić jego rozwijanie i dokumentację przez współtwórców.

Katalog przestrzeni nazw projektu

Katalog przestrzeni nazw projektu to najwyższy poziom katalogu Twojego projektu, który definiuje jego strukturę. Na przykład, jeśli masz projekt deweloperski o nazwie kdevops i wszystkie jego pliki są przechowywane w:

/home/user/devel/kdevops/

W tym przypadku katalog przestrzeni nazw projektu to kdevops. Domyślnie ta rola Ansible określa katalog przestrzeni nazw projektu na podstawie nazwy katalogu, w którym znajduje się plik playbook, który wywołuje tę rolę. Na przykład, jeśli plik playbook znajduje się w:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes.yml

Możesz nadpisać dane w innym pliku:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Katalog, w którym przechowywany jest Twój plik playbook, to:

/home/user/devel/kdevops/playbooks/

Nazwa katalogu to:

/home/user/devel/kdevops/

To będzie domyślny katalog przestrzeni nazw projektu. Możesz to nadpisać, używając zmiennej roli force_project_dir, opisanej poniżej.

Przestrzeń nazw projektu

Przestrzeń nazw projektu jest używana w pliku Vagrantfile dostarczanym przez tę rolę, aby umożliwić Ci nadpisanie domyślnych ustawień używanych przez Vagrant za pomocą zmiennych środowiskowych. Przestrzeń nazw projektu jest określana z katalogu przestrzeni nazw projektu opisanego powyżej. Na przykład, w przypadku, gdy katalog przestrzeni nazw projektu to:

/home/user/devel/kdevops/

Przestrzeń nazw projektu będzie określona jako kdevops. Wersja z dużymi literami jest używana jako prefiks dla zmiennych środowiskowych, więc KDEVOPS. Myślniki są zamieniane na podkreślniki, ponieważ zmienne w powłoce nie mogą zawierać myślników. Zatem, jeśli katalog przestrzeni nazw projektu to:

/home/user/devel/some-cool-project/

Przestrzeń nazw projektu byłaby: SOME_COOL_PROJECT

Wymagania

Musisz mieć zainstalowany Vagrant.

Vagrant jest używany do łatwego wdrażania maszyn wirtualnych niezwiązanych z chmurą. Poniżej znajduje się lista obsługiwanych dostawców:

VirtualBox
libvirt (KVM)

Obsługiwane systemy operacyjne:

OS X
Linux

Uruchamianie libvirt jako zwykły użytkownik

Korzystamy z roli Ansible libvirt-user, aby umożliwić działanie zwykłego użytkownika. Przeczytaj dokumentację tam, aby poznać szczegóły.

Nadpisywanie konfiguracji węzłów innym plikiem

Lepszym sposobem na obsługę nadpisywania zmiennych używanych w Vagrant jest użycie pliku $(project)_node_override.yaml. Na przykład, dla projektu kdevops, możesz nadpisać dane w innym opcjonalnym pliku przechowywanym poza systemem kontroli wersji:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Zmiennie środowiskowe

Tylko jeśli użycie pliku nadpisania nie działa, można użyć zmiennych środowiskowych. Jednak korzystanie z nich jest realizowane na zasadzie indywidualnej, ponieważ musimy wdrożyć obsługę dla każdej nowej zmiennej, która zostanie dodana. Kiedy korzystasz z pliku nadpisania, możesz nadpisywać wszystko, gdy tylko zostanie dodana nowa funkcja.

Zmiennie środowiskowe mają prefiks w postaci wersji z dużymi literami przestrzeni nazw projektu, jak opisano powyżej. Od teraz odwołujmy się do tego jako ${PN_U}. Biorąc pod uwagę ten prefiks, następujące zmienne środowiskowe modyfikują działanie pliku Vagrantfile:

${PN_U}_VAGRANT_NODE_CONFIG: pozwala nadpisać domyślny plik konfiguracyjny
${PN_U}_VAGRANT_PROVIDER: pozwala nadpisać dostawcę używanego przez Vagrant
${PN_U}_VAGRANT_LIMIT_BOXES: pozwala włączyć limit boxów
${PN_U}_VAGRANT_LIMIT_NUM_BOXES: liczba boxów do ograniczenia
${PN_U}_VAGRANT_QEMU_GROUP: nadpisuje użytkownika qemu, którego należy użyć

Ograniczenie liczby boxów Vagrant

Domyślnie Vagrant spróbuje utworzyć wszystkie węzły określone w Twoim pliku konfiguracyjnym węzłów. Domyślnie jest to ${PN_L}_nodes.yml, gdzie $PN_L to wersja mała przestrzeni nazw projektu opisana powyżej. Na przykład, dla projektu kdevops byłoby to kdevops_nodes.yml.

Na przykład, jeśli chcesz ograniczyć Vagrant do utworzenia jednego boxu w projekcie kdevops, możesz użyć:

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

Oczywiście użyjesz innego prefiksu dla projektów o różnych nazwach.

To zapewni, że tylko pierwszy węzeł, na przykład, zostanie utworzony i skonfigurowany. Może to być przydatne, jeśli rozwijasz na laptopie i chcesz ograniczyć użycie zasobów.

Zakres użycia Ansible

kdevops jako całość jest zaprojektowany tak, aby nie był zależny od sposobu, w jaki konfigurujesz system, niezależnie od tego, czy używasz wirtualizowanego lokalnego systemu z libvirt/VirtualBox, systemu bare metal, czy środowiska chmurowego.

Z tego powodu istnieją 3 etapy uruchamiania:

Uruchamianie: wirtualne / w chmurze / bare metal
Konfiguracja i instalacja zależności: dodanie systemów do ~/.ssh/config oraz instalacja preferowanych skryptów bash, .gitconfig i pakietów deweloperskich. To jest obsługiwane przez rolę Ansible update_ssh_config_vagrant oraz devconfig.
Praca: wykonuj swoje zadania, co zwykle teraz jest promowane przez Ansible.

Nasze wykorzystanie Vagrant z Ansible ogranicza się do pierwszych dwóch wymienionych części. Używamy Ansible tylko do wykorzystania dwóch ról Ansible:

Celowo nie chcemy rozszerzać tej praktyki, ponieważ chcemy, aby użytkownicy korzystali bezpośrednio z Ansible w przyszłości. Prace związane z uruchamianiem, konfigurowaniem i instalowaniem zależności deweloperskich muszą być obsługiwane przez Vagrant, Terraform lub użytkownika, który ręcznie konfiguruje systemy bare metal.

Z tego powodu nie zachęcamy do dodawania większej liczby ról Ansible do użycia z Vagrant. Te dwie role powinny wystarczyć dla typowych konfiguracji, a reszta użycia Ansible powinna być realizowana ręcznie.

Interpreter Pythona Ansible

Ansible polega na Pythonie na zdalnych systemach. Jaka wersja Pythona powinna być używana, będzie się różnić, ale domyślnie Ansible spróbuje użyć starszej wersji interpretera Pythona, aby wspierać starsze systemy. Ta decyzja nie jest najlepsza dla nowszych systemów, dlatego zaleca się określenie interpretera. Najlepiej ustawić go w pliku inwentarza. Plik Vagrantfile zakłada, że masz plik inwentarza o nazwie ../hosts, możesz jednak to nadpisać w konfiguracji Ansible w sposób następujący:

ansible_playbooks:
  # Jeśli ten plik istnieje, możesz tam nadpisać dowolną zmienną Ansible.
  # Ten plik jest opcjonalny.
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

Twój plik hosts może wyglądać mniej więcej tak:

[all]
newsystem1
oldsystem1
[all:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[new]
newsystem1
[new:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[old]
oldsystem1
[dev:vars]
ansible_python_interpreter =  "/usr/bin/python2"

W tym przypadku grupa [all] ustawia interpreter Pythona na python3, jednak ostatni wpis zapewnia, że stary system używa zamiast tego pythona2.

Dodatkowe zmienne Ansible używane z Vagrant

Ansible ma swoją hierarchię, według której zmienne mają pierwszeństwo, przez co umożliwiają użycie ich w linii poleceń, plikach ról itp. Jest to udokumentowane na stronie dokumentacji dotyczącej zmiennych w playbookach Ansible.

Chociaż może to pasować do większości zastosowań, to jednak nie pomaga w projektach, które chcą umożliwić użytkownikom określenie własnych wariantów domyślnych w pliku, który nie jest obecny w systemie kontroli wersji, bez konieczności rozwijania w linii poleceń.

Ponieważ kdevops składa się z jednolitego zestawu ról Ansible, wspieramy jednolity sposób definiowania nadpisania dla Ansible. Robimy to, pozwalając użytkownikowi nadpisać zmienne Ansible w katalogu głównym projektu w pliku o nazwie:

extra_vars.yml

Więc w przypadku projektu kdevops byłoby to:

/home/user/devel/kdevops/extra_vars.yml

Kiedy ten plik jest ustawiony, wtyczka Vagrant Ansible upewni się, że plik jest bezpośrednio przekazywany do Ansible w linii poleceń za pomocą --extra-vars=@file. Prefiks @ jest wymagany, gdy określasz plik. Nie musisz podawać @, my to robimy za Ciebie.

Wszystkie używane role Ansible w kdevops wspierają poszukiwanie tego pliku extra_vars.

Zmienne roli Ansible

run_vagrant: domyślnie jest False, jeśli ustawione na True, uruchomimy Vagrant za Ciebie
force_project_dir: jeśli ustawione, będzie to używane jako katalog, w którym będziemy szukać katalogu Vagrant i ostatecznie skopiujemy plik Vagrantfile. Domyślnie jest to ustawione na pusty, a my określamy twój katalog projektu jako katalog nadrzędny, w którym znajdował się plik playbook.

Zależności

Brak.

Przykładowy playbook

Poniżej znajduje się przykład playbooka, który jest używany w projekcie kdevops, w pliku kdevops/playbooks/kdevops_vagrant.yml:

---
- hosts: localhost
  roles:
    - role: kdevops_vagrant

W tym szczególnym przypadku zauważ, że użyto localhost. Dzieje się tak, ponieważ wdrażamy plik Vagrantfile do katalogu kdevops/vagrant/ lokalnie. Oczywiście możesz użyć innego hosta.