Projekty
Projekt to kolekcja zasobów, które definiują konfiguracje węzłów. Projekty zawierają specyfikacje. Po uruchomieniu węzła jest on konfigurowany przez przetwarzanie i uruchamianie sekwencji specyfikacji.
Usługa Azure CycleCloud używa projektów do zarządzania aplikacjami klastra, takimi jak harmonogramy wsadowe. W cyklu CycleCloud HPCPack projekt jest specyfikacją i cn specyfikacjąhn, która definiuje konfiguracje i przepisy dotyczące węzła głównego i węzła obliczeniowego HPCPack.
Poniżej znajduje się definicja węzła częściowego. Węzeł docker-registry będzie uruchamiać trzy specyfikacje: powiązać specyfikację z projektu okta w wersji 1.3.0, a także specyfikacje podstawowe i rejestru z projektu platformy Docker w wersji 2.0.0:
[[node docker-registry]]
Locker = base-storage
[[[cluster-init okta:bind:1.3.0]]]
[[[cluster-init docker:core:2.0.0]]]
[[[cluster-init docker:registry:2.0.0]]]
Końcowy tag to numer wersji projektu.
[[[cluster-init <project>:<spec>:<project version>]]]
Szafka jest odwołaniem do kontenera konta magazynu i poświadczeń. Węzły mają domyślną funkcję locker, więc ten atrybut nie jest ściśle konieczny.
Usługa Azure CycleCloud używa skrótu dla kont magazynu, więc https://mystorage.blob.core.windows.net/mycontainer można je zapisać jako az://mystorage/mycontainer.
Węzeł pobierze każdy projekt, do których odwołuje się on z szafki przy użyciu narzędzia pogo:
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Jeśli projekt jest zdefiniowany w węźle, ale nie istnieje w oczekiwanej lokalizacji magazynu, węzeł zgłosi Software Installation Failure element do aplikacji CycleCloud.
Usługa CycleCloud ma projekty wewnętrzne, które są domyślnie uruchamiane na wszystkich węzłach w celu wykonywania specjalnej obsługi woluminów i sieci oraz konfigurowania komunikacji z aplikacją CycleCloud. Te projekty wewnętrzne są automatycznie dublowane do szafki.
Użytkownik jest odpowiedzialny za dublowanie wszelkich dodatkowych projektów w szafce. Interfejs wiersza polecenia cycleCloud zawiera metody tworzenia projektów:
cyclecloud project init myproject
i lustro:
cyclecloud project init mylocker
projekty do zamknięć.
Specyfikacje składają się z skryptów języka Python, powłoki lub programu PowerShell.
Tworzenie nowego projektu
Aby utworzyć nowy projekt, użyj polecenia interfejsu wiersza polecenia cyclecloud project init myproject, gdzie myproject jest nazwą projektu, który chcesz utworzyć. Spowoduje to utworzenie projektu o nazwie "myproject" z pojedynczą specyfikacją o nazwie "default", którą można zmienić. Drzewo katalogów zostanie utworzone z plikami szkieletów, które zmienisz w celu uwzględnienia własnych informacji.
Struktura katalogu
Następujące katalogi zostaną utworzone przez polecenie projektu:
\myproject
├── project.ini
├── blobs
├── templates
├── specs
│ ├── default
│ └── cluster-init
│ ├── scripts
│ ├── files
│ └── tests
│ └── chef
│ ├── site-cookbooks
│ ├── data_bag
│ └── roles
Katalog templates będzie przechowywać szablony klastra, natomiast specyfikacje będą zawierać specyfikacje definiujące projekt. Spec ma dwa podkatalogi: cluster-init i custom chef. cluster-init zawiera katalogi, które mają specjalne znaczenie, takie jak katalog scripts (zawiera skrypty wykonywane w kolejności leksykograficznej w węźle), pliki (nieprzetworzone pliki danych do umieszczenia w węźle) i testy (zawiera testy do uruchomienia po uruchomieniu klastra w trybie testowania).
Niestandardowy podkatalog chef ma trzy katalogi: podręczniki witryny (w przypadku definicji książek kucharskich), data_bags (definicje worków danych) i role (pliki definicji roli szefa kuchni).
project.ini
project.ini to plik zawierający wszystkie metadane projektu. Może zawierać następujące elementy:
| Parametr | Opis |
|---|---|
| name | Nazwa projektu. Wyrazy muszą być oddzielone kreskami, np. order-66-2018 |
| label | Nazwa projektu. Długa nazwa (z spacjami) klastra na potrzeby wyświetlania. |
| typ | Trzy opcje: harmonogram, aplikacja, <puste>. Określa typ projektu i generuje odpowiedni szablon. Ustawienie domyślne: aplikacja |
| Wersja | Format: x.x.x |
Szafki
Zawartość projektu jest przechowywana w szafce. Zawartość projektu można przekazać do dowolnej funkcji zdefiniowanej w instalacji narzędzia CycleCloud za pomocą polecenia cyclecloud project upload (locker), gdzie (locker) jest nazwą szafki magazynu w chmurze w instalacji usługi CycleCloud. Ta funkcja zostanie ustawiona jako domyślny element docelowy. Możesz też zobaczyć, jakie blokady są dostępne za pomocą polecenia cyclecloud locker list. Szczegółowe informacje o określonej szafce można wyświetlić za pomocą polecenia cyclecloud locker show (locker).
Jeśli dodasz więcej niż jedną funkcję, możesz ustawić wartość domyślną za pomocą cyclecloud project default_target (locker)polecenia , a następnie po prostu uruchomić polecenie cyclecloud project upload. Można również ustawić globalną domyślną funkcjęlocker, która może być udostępniana przez projekty za pomocą polecenia cyclecloud project default locker (locker) -global.
Uwaga
Domyślne blokady będą przechowywane w pliku konfiguracji cyclecloud (zwykle znajduje się w lokalizacji ~/.cycle/config.ini), a nie w project.ini. Ma to na celu umożliwienie kontroli wersji project.ini.
Przekazanie zawartości projektu spowoduje spakowanie katalogów chef i zsynchronizowanie zarówno narzędzia Chef, jak i inicjowania klastra z funkcją docelową. Będą one przechowywane w:
- (locker)/projects/(project)/(version)/(spec_name)/cluster-init
- (locker)/projects/(project)/(version)/(spec_name)/chef
Pobieranie obiektów blob
Użyj polecenia project download , aby pobrać wszystkie obiekty blob, do których odwołuje się project.ini, do lokalnego katalogu obiektów blob. Polecenie używa parametru [locker] i podejmie próbę pobrania obiektów blob wymienionych w project.ini z funkcjilocker do magazynu lokalnego. Jeśli nie można znaleźć plików, zostanie zwrócony błąd.
Konfiguracja projektu
Specyfikacje
Podczas tworzenia nowego projektu definiowana jest pojedyncza domyślna specyfikacja. Dodatkowe specyfikacje można dodać do projektu za pomocą cyclecloud project add_spec polecenia .
Przechowywanie wersji
Domyślnie wszystkie projekty mają wersję 1.0.0. Wersję niestandardową można ustawić podczas opracowywania i wdrażania projektów, ustawiając w version=x.y.z pliku project.ini .
Jeśli na przykład "locker_url" to "az://my-account/my-container/projects", projekt miał nazwę "Order66", wersja to "1.6.9", a specyfikacja to "default", adres URL będzie:
- az://my-account/my-container/projects/Order66/1.6.9/default/cluster-init
- az://my-account/my-container/projects/Order66/1.6.9/default/chef
Obiekty blob
Istnieją dwa typy obiektów blob: obiekty blob projektu i obiekty blob użytkownika.
Obiekty blob projektu
Obiekty blob projektu to pliki binarne dostarczane przez autora projektu z założeniem, że mogą być dystrybuowane (tj. plik binarny dla projektu open source, który można legalnie rozpowszechnić). Obiekty blob projektu przechodzą do katalogu "obiekty blob" projektu, a po przekazaniu do szafki będą one znajdować się w lokalizacji /project/blobs.
Aby dodać obiekty blob do projektów, dodaj pliki do project.ini:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
Wiele obiektów blob można rozdzielić przecinkami. Można również określić ścieżkę względną do katalogu obiektów blob projektu.
Obiekty blob użytkownika
Obiekty blob użytkownika to pliki binarne, których autor projektu nie może legalnie rozpowszechnić, takich jak pliki binarne UGE. Te pliki nie są pakowane w projekcie, ale zamiast tego muszą być przygotowane ręcznie do szafki. Pliki będą znajdować się w lokalizacji /blobs/my-project/my-blob.tgz. Obiekty blob użytkownika nie muszą być zdefiniowane w project.ini.
Aby pobrać dowolny obiekt blob, użyj jetpack download polecenia z interfejsu jetpack_download wiersza polecenia lub zasobu Chef. Usługa CycleCloud najpierw wyszuka obiekt blob użytkownika. Jeśli ten plik nie znajduje się, zostanie użyty obiekt blob na poziomie projektu.
Uwaga
Istnieje możliwość zastąpienia obiektu blob projektu za pomocą obiektu blob użytkownika o tej samej nazwie.
Określanie projektu w szablonie klastra
Składnia projektu umożliwia określenie wielu specyfikacji w węzłach. Aby zdefiniować projekt, użyj następujących elementów:
[[[cluster-init myspec]]]
Project = myproject # inferred from name
Version = x.y.z
Spec = default # (alternatively, you can name your own spec to be used here)
Locker = default # (optional, will use default locker for node)
Uwaga
Nazwa określona po specyfikacji może być niczym, ale może i powinna być używana jako skrót do zdefiniowania niektórych > typowych właściwości.
Można również zastosować wiele specyfikacji do danego węzła w następujący sposób:
[[node scheduler]]
[[[cluster-init myspec]]]
Project = myproject
Version = x.y.z
Spec = default # (alternatively, you can name your own spec to be used here)
Locker = default # (optional, will use default locker for node)
[[[cluster-init otherspec]]]
Project = otherproject
Version = a.b.c
Spec = otherspec # (optional)
Oddzielając nazwę projektu, nazwę specyfikacji i wersję dwukropkami, usługa CycleCloud może automatycznie analizować te wartości w odpowiednich Project/Version/Spec ustawieniach:
[[node scheduler]]
AdditionalClusterInitSpecs = $ClusterInitSpecs
[[[cluster-init myproject:myspec:x.y.z]]]
[[[cluster-init otherproject:otherspec:a.b.c]]]
Specyfikacje można również dziedziczyć między węzłami. Na przykład można udostępnić wspólną specyfikację między wszystkimi węzłami, a następnie uruchomić niestandardową specyfikację w węźle harmonogramu:
[[node defaults]]
[[[cluster-init my-project:common:1.0.0]]]
Order = 2 # optional
[[node scheduler]]
[[[cluster-init my-project:scheduler:1.0.0]]]
Order = 1 # optional
[[nodearray execute]]
[[[cluster-init my-project:execute:1.0.0]]]
Order = 1 # optional
Spowoduje to zastosowanie zarówno specyfikacji, jak common i scheduler do węzła harmonogramu, przy jednoczesnym zastosowaniu common tylko specyfikacji i execute do środowiska nodearray wykonywania.
Domyślnie specyfikacje będą uruchamiane w kolejności, w której są wyświetlane w szablonie, uruchamiając najpierw dziedziczone specyfikacje. Order jest opcjonalną liczbą całkowitą ustawioną na wartość domyślną 1000 i może służyć do definiowania kolejności specyfikacji.
Jeśli w [[[cluster-init]]] definicji określono tylko jedną nazwę, przyjmuje się, że będzie to nazwa specyfikacji. Przykład:
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
jest prawidłową konfiguracją specyfikacji, w której Spec=myspec jest implikowane przez nazwę.
run_list
Listę uruchamiania można określić na poziomie projektu lub specyfikacji w ramach project.ini:
[spec scheduler]
run_list = role[a], recipe[b]
Gdy węzeł zawiera specyfikację "scheduler", zdefiniowana run_list zostanie automatycznie dołączona do dowolnej wcześniej zdefiniowanej listy runlist. Jeśli na przykład moja run_list zdefiniowana w obszarze [configuration] to run_list = recipe[test], ostateczna lista runlisty będzie miała wartość run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
Możesz również zastąpić listę uruchamiania na poziomie specyfikacji w węźle. Spowoduje to zastąpienie wszystkich run_list uwzględnionych w project.ini. Jeśli na przykład zmieniliśmy definicję węzła na następującą:
[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]
Lista runlista zdefiniowana w projekcie zostanie zignorowana, a powyższe zamiast tego zostaną użyte. Ostateczna lista uruchamiania w węźle to run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].
Uwaga
Listy runlist są specyficzne dla szefa kuchni i nie mają zastosowania w przeciwnym razie.
Lokalizacje plików
Spakowane pliki chef zostaną pobrane podczas fazy uruchamiania węzła rozruchowego. Są one pobierane do $JETPACK_HOME/system/chef/tarballs i rozpakowane do $JETPACK_HOME/system/chef/chef-repo/i używane podczas zbieżnia węzła.
Uwaga
Aby uruchomić niestandardowe książki kucharskie, musisz określić je w run_list dla węzła.
Pliki cluster-init zostaną pobrane do pliku /mnt/cluster-init/(project)/(spec)//. W przypadku "my-project" i "my-spec" zobaczysz skrypty, pliki i testy znajdujące się w folderze /mnt/cluster-init/my-project/my-spec.
Synchronizowanie projektów
Projekty CycleCloud można synchronizować z dublowania do lokalnego magazynu w chmurze klastra. Ustaw atrybut Funkcji SourceLocker w [cluster-init] sekcji w szablonie. Określona nazwa funkcji będzie używana jako źródło projektu, a zawartość zostanie zsynchronizowana z funkcją locker podczas uruchamiania klastra. Możesz również użyć nazwy funkcji locker jako pierwszej części nazwy inicjatora klastra. Jeśli na przykład funkcja źródłowa miała wartość "cyclecloud", następujące dwie definicje są takie same:
[cluster-init my-project:my-spect:1.2.3]
SourceLocker=cyclecloud
[cluster-init cyclecloud/my-proect:my-spec:1.2.3]
Duży magazyn plików
Projekty obsługują duże pliki. Na najwyższym poziomie nowo utworzonego projektu zostanie wyświetlony katalog "blobs" dla dużych plików (obiektów blob). Należy pamiętać, że obiekty blob umieszczone w tym katalogu mają określony cel i działają inaczej niż elementy w katalogu "files".
Elementy w katalogu "blobs" są niezależne od specyfikacji i wersji: wszystkie elementy w "obiektach blob" mogą być współużytkowane między specyfikacjami lub wersjami projektu. Na przykład instalator programu, który często zmienia się, może być przechowywany w "obiektach blob" i przywołyny w project.ini. Podczas iterowania wersji projektu pojedynczy plik pozostaje taki sam i jest kopiowany tylko do magazynu w chmurze raz, co pozwala zaoszczędzić na kosztach transferu i magazynowania.
Aby dodać obiekt blob, wystarczy umieścić plik w katalogu "blobs" i edytować project.ini , aby odwołać się do tego pliku:
[blobs]
Files=big_file1.tgz
W przypadku korzystania z project upload polecenia wszystkie obiekty blob, do których odwołuje się project.ini zostaną przeniesione do magazynu w chmurze.
Pliki dziennika
Pliki dziennika generowane podczas uruchamiania klastra-init znajdują się w $JETPACK_HOME/logs/cluster-init/(project)/(spec).
Uruchamianie plików
Po pomyślnym uruchomieniu skryptu cluster-init plik jest umieszczany w pliku /mnt/cluster-init/.run/(project)/(spec), aby upewnić się, że nie zostanie on uruchomiony ponownie w kolejnym konwercie. Jeśli chcesz ponownie uruchomić skrypt, usuń odpowiedni plik w tym katalogu.
Katalogi skryptów
Gdy usługa CycleCloud wykonuje skrypty w katalogu scripts, doda zmienne środowiskowe do ścieżki i nazwy katalogów specyfikacji i projektów:
CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH
W systemie Linux projekt o nazwie "test-project" ze specyfikacją "default" będzie miał ścieżki w następujący sposób:
CYCLECLOUD_PROJECT_NAME = test-project
CYCLECLOUD_PROJECT_PATH = /mnt/cluster-init/test-project
CYCLECLOUD_SPEC_NAME = default
CYCLECLOUD_SPEC_PATH = /mnt/cluster-init/test-project/default
Uruchamianie tylko skryptów
Aby uruchomić tylko skrypty cluster-init:
jetpack converge --cluster-init
Dane wyjściowe z polecenia będą przechodzić do pliku STDOUT, a także jetpack.log. Każdy skrypt będzie również miał zarejestrowane dane wyjściowe:
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Niestandardowa specyfikacja szefa kuchni i komposable
Każda specyfikacja ma w nim katalog chef. Przed zbieżniem każda specyfikacja zostanie rozpakowana i wyodrębniona do lokalnego repozytorium szefa kuchni, zastępując wszystkie istniejące książki kucharskie, role i torby na dane o takich samych nazwach. Odbywa się to w kolejności zdefiniowanej specyfikacji, więc w przypadku kolizji nazewnictwa ostatnia zdefiniowana specyfikacja zawsze wygra.
pobieranie pakietu jetpack
Aby pobrać obiekt blob w skryscie cluster-init, użyj polecenia jetpack download (filename) , aby pobrać go z katalogu obiektów blob. Uruchomienie tego polecenia ze skryptu cluster-init określi projekt i podstawowy adres URL. Aby użyć go w kontekście innego niż klaster,należy określić projekt (zobacz --help, aby uzyskać więcej informacji).
Dla użytkowników kuchni utworzono elementy jetpack_download LWRP:
jetpack_download "big-file1.tgz" do
project "my-project"
end
W programie chef domyślną lokalizacją pobierania jest #{node[:jetpack][:downloads]}. Aby zmienić miejsce docelowe pliku, użyj następujących elementów:
jetpack_download "foo.tgz" do
project "my-project"
dest "/tmp/download.tgz"
end
W przypadku użycia w programie Chef należy określić projekt.