Projekty

Projekt to kolekcja zasobów, które definiują konfiguracje węzłów. Projekty zawierają specyfikacje. Po uruchomieniu węzła przetwarza i uruchamia sekwencję specyfikacji w celu skonfigurowania węzła.

Usługa Azure CycleCloud używa projektów do zarządzania aplikacjami klastrowymi, takimi jak harmonogramy wsadowe. W klastrze CycleCloud HPCPack projekt używa specyfikacji hn i cn do definiowania konfiguracji i skryptów dotyczących węzła głównego i węzła obliczeniowego HPCPack.

W poniższej definicji węzła częściowego węzeł docker-registry uruchamia trzy specyfikacje: specyfikację bind z projektu Okta w wersji 1.3.0 oraz specyfikacje core i registry z projektu 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>]]]

Locker jest odwołaniem do kontenera konta magazynowego i poświadczeń. Węzły mają domyślną blokadę, więc nie zawsze trzeba określać ten atrybut.

Usługa Azure CycleCloud używa skrótu dla kont magazynowych. Można na przykład napisać https://mystorage.blob.core.windows.net/mycontainerjako az://mystorage/mycontainer.

Jeśli zdefiniujesz projekt w węźle, ale nie istnieje on w oczekiwanej lokalizacji magazynu, węzeł zgłosi Software Installation Failure do 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 woluminu i sieci oraz konfigurowania komunikacji z usługą CycleCloud. System automatycznie dubluje te projekty wewnętrzne do funkcji locker.

Odpowiadasz za zwierciadlenie wszelkich dodatkowych projektów do serwerowni. Interfejs wiersza poleceń CycleCloud CLI oferuje metody do komponowania projektów.

cyclecloud project init myproject

Projekty dublowania do zamknięć:

cyclecloud project init mylocker

Specyfikacje składają się ze skryptów języka Python, powłoki lub programu PowerShell.

Tworzenie nowego projektu

Aby utworzyć nowy projekt, użyj polecenia CLI cyclecloud project init myproject, gdzie myproject jest nazwą projektu, który chcesz utworzyć. myproject ma jedną default specyfikację, którą można zmienić. Polecenie tworzy drzewo katalogów ze szkieletowymi plikami, które aktualizujesz własnymi danymi.

Struktura katalogu

Polecenie projektu tworzy następujące katalogi:

      myproject
          ├── project.ini
          ├── blobs
          ├── templates
          ├── specs
          │   ├── default
          │     └── cluster-init
          │        ├── scripts
          │        ├── files
          │        └── tests

Katalog templates zawiera szablony klastrów, natomiast specyfikacje zawierają specyfikacje definiujące projekt. Katalog specs ma podkatalog o nazwie cluster-init (ale zobacz również Chef Orchestration). Katalog cluster-init zawiera katalogi ze specjalnymi znaczeniami, w tym katalog skryptów (który zawiera skrypty uruchamiane w kolejności leksykograficznej w węźle), pliki (zawierające nieprzetworzone pliki danych, które przechodzą do węzła) i testy (zawierające testy uruchamiane po uruchomieniu klastra w trybie testowania).

project.ini

project.ini to plik zawierający wszystkie metadane projektu. Może zawierać następujące elementy:

Szafki

Zawartość projektu jest przechowywana w szafce. Zawartość projektu można przesłać do dowolnego lockera zdefiniowanego w instalacji usługi CycleCloud, uruchamiając polecenie cyclecloud project upload (locker), gdzie (locker) jest nazwą lockera magazynowego w instalacji usługi CycleCloud. Ten schowek jest domyślnym celem. Możesz również uruchomić polecenie cyclecloud locker list, aby sprawdzić, jakie skrytki są dla Ciebie dostępne. Szczegółowe informacje o określonej funkcji można wyświetlić za pomocą polecenia cyclecloud locker show (locker).

Jeśli dodasz więcej niż jedną szafkę, możesz ustawić domyślną szafkę za pomocą cyclecloud project default_target (locker), a następnie uruchomić cyclecloud project upload. Można również ustawić globalne domyślne repozytorium dla projektów do wspólnego korzystania, uruchamiając polecenie cyclecloud project default locker (locker) -global.

Po przekazaniu zawartości projektu usługa CycleCloud synchronizuje zawartość cluster-init z docelowym schowkiem pod adresem projects/(project)/(version)/(spec_name)/cluster-init.

Pobieranie danych blob

Użyj project download, aby pobrać wszystkie obiekty blob, do których odwołuje się project.ini, do lokalnego katalogu blobów. Polecenie używa parametru [locker] i próbuje pobrać bloby wymienione w project.ini ze schowka do magazynu lokalnego. Jeśli polecenie nie może odnaleźć plików, zwraca błąd.

Konfiguracja projektu

Specyfikacje

Podczas tworzenia nowego projektu należy zdefiniować jedną default specyfikację. Użyj cyclecloud project add_spec polecenia , aby dodać więcej specyfikacji do projektu.

Wersjonowanie

Domyślnie wszystkie projekty używają wersji 1.0.0. Ustaw wersję niestandardową podczas opracowywania i wdrażania projektów przez ustawienie version=x.y.z w pliku project.ini .

Jeśli na przykład locker_url to az://my-account/my-container/projects, nazwa projektu to "Order66", wersja to 1.6.9, a specyfikacją jest default, adres URL to:

az://my-account/my-container/projects/Order66/1.6.9/default

Blobów

Istnieją dwa typy obiektów blob: obiekty blob projektu i obiekty blob użytkownika.

Projekt Bloby

Autorzy projektów dostarczają bloby projektu, które są plikami binarnymi możliwymi do rozpowszechniania (na przykład pliki binarne dla projektu open-source, które ktoś może legalnie redystrybuować). Bloby projektu przechodzą do blobs katalogu projektu i są umieszczane w /project/blobs po przesłaniu ich do schowka.

Aby dodać obiekty blob do projektów, dodaj pliki do project.ini:

[[blobs optionalname]]
  Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz

Oddzielaj wiele obiektów blob przecinkami. Można również określić ścieżkę względną do katalogu obiektów blob projektu.

Bloby użytkownika

Obiekty blob użytkownika to pliki binarne, takie jak pliki binarne Univa Grid Engine, których autor projektu nie może legalnie dystrybuować. Te pliki nie są pakowane w projekcie. Użytkownicy muszą ręcznie umieścić je w swoim schowku. Pliki znajdują się w folderze /blobs/my-project/ w funkcji locker (na przykład /blobs/my-project/my-blob.tgz). Nie musisz definiować obiektów blob użytkownika w project.ini.

Aby pobrać dowolny obiekt blob, użyj jetpack download polecenia. Usługa CycleCloud najpierw wyszukuje obiekt blob użytkownika, a jeśli nie może zlokalizować pliku, korzysta z obiektu blob na poziomie projektu.

Określanie projektów w szablonie klastra

Specyfikacje są definiowane w szablonie klastra przy użyciu [[[cluster-init]]]sekcji w węźle:

[[node defaults]]
[[[cluster-init my-project:common:1.0.0]]]

[[node scheduler]]
[[[cluster-init my-project:scheduler:1.0.0]]]

[[nodearray execute]]
[[[cluster-init my-project:execute:1.0.0]]]

W tym przykładzie wykorzystuje się definicję węzła defaults, którą dziedziczą wszystkie węzły. Węzeł harmonogramu pobiera specyfikacje common i scheduler, a węzły w tablicy węzłów wykonawczych otrzymują specyfikacje common i execute.

Lokalizacje plików

Węzeł pobiera pliki inicjalizacyjne klastra do lokalizacji /mnt/cluster-init/(project)/(spec)/. W systemach my-project i my-spec, skrypty, pliki i testy znajdują się w elemencie /mnt/cluster-init/my-project/my-spec.

Synchronizowanie projektów

Projekty CycleCloud można synchronizować z kopii lustrzanych do lokalnej przestrzeni dyskowej w chmurze klastra. SourceLocker Ustaw atrybut w [cluster-init] sekcji w szablonie. Nazwa określonej szafki to źródło projektu, a zawartość jest synchronizowana z szafką, gdy klaster się uruchamia. Możesz również użyć nazwy szafki jako pierwszej części cluster-init nazwy. Na przykład, jeśli szafka źródłowa to 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 blobs katalog dla dużych plików (blobów). Obiekty blobów umieszczone w tym katalogu mają określony cel i działają inaczej niż elementy znajdujące się w files katalogu.

Elementy w blobs katalogu działają niezależnie od specyfikacji i wersji. Możesz udostępniać dowolne elementy między specyfikacjami lub wersjami projektu w obiektach blob. Można na przykład przechowywać instalator programu, który rzadko się zmienia, w obiektach blob i odnosić się do niego w project.ini. W miarę iteracji wersji projektu pojedynczy plik pozostaje taki sam i kopiuje do magazynu w chmurze raz, co pozwala zaoszczędzić na kosztach transferu i magazynowania.

Aby dodać blob, umieść plik w blobs katalogu i edytuj project.ini, aby odwoływać się do tego pliku.

[blobs]
  Files=big_file1.tgz

Gdy używasz polecenia project upload, wszystkie obiekty blob odwoływane przez project.ini są przesyłane do magazynu w chmurze.

Pliki dziennika

Pliki dziennika generowane podczas uruchamiania pliku cluster-init znajdują się w folderze $JETPACK_HOME/logs/cluster-init/(project)/(spec).

Uruchamianie plików

Po pomyślnym uruchomieniu skryptu cluster-init umieszcza on plik w /mnt/cluster-init/.run/(project)/(spec), aby upewnić się, że skrypt nie zostanie uruchomiony ponownie podczas kolejnej konwergencji. Aby ponownie uruchomić skrypt, usuń odpowiedni plik w tym katalogu.

Katalogi skryptów

Gdy usługa CycleCloud wykonuje skrypty w scripts katalogu, dodaje zmienne środowiskowe do ścieżki i nazwy spec i project katalogów.

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

W systemie Linux projekt o nazwie test-project ze specyfikacją default zawiera następujące ścieżki:

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, użyj następującego polecenia:

jetpack converge --cluster-init

Polecenie wysyła dane wyjściowe do elementu STDOUT i do jetpack.log. Dane wyjściowe każdego skryptu są również rejestrowane w następujących lokalizacjach:

      $JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out

pobieranie pakietu jetpack

Aby pobrać blob w skrypcie cluster-init, użyj polecenia jetpack download (filename), aby ściągnąć go z katalogu blobs. Uruchomienie tego polecenia ze skryptu cluster-init umożliwia określenie projektu i podstawowego adresu URL. Aby używać go w kontekście innym niż inicjalizacja klastra, należy określić projekt. Aby uzyskać więcej informacji, użyj --help opcji .