Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

DevOps w chmurze Amazonu

Autor: Piotr Karpiuk o 2. czerwca 2017

Wielką popularnością obecnie cieszy się programowanie zwinne (ang. agile software development), które rozpoczęło żywot w 2001 roku, a z czasem zdobyło wielką popularność i dość skutecznie wyparło tradycyjny „wodospadowy” model tworzenia oprogramowania. Metodyki zwinne odnoszą się zwłaszcza do współpracy pomiędzy programistami a użytkownikami biznesowymi.

Tymczasem w czeluściach procesu tworzenia oprogramowania czai się jeszcze inny konflikt, tym razem w obrębie organizacji: pomiędzy deweloperami a osobami odpowiedzialnymi za wdrożenie oprogramowania. Tradycyjnie w dużych firmach IT deweloperzy chcą szybko tworzyć i modyfikować oprogramowanie, podczas gdy na drodze staje im dział eksploatacji (ang. IT operations, czyli administratorzy, architekci infrastruktury sprzętowej i personel wsparcia klienta) zainteresowany głównie stabilnością i niezawodnością, a nie zmianami (patrz kultowy rysunek obok, pochodzący z jednej z pierwszych konferencji DevOps w 2010 roku). Na konflikcie interesów traci cała firma.

DevOps to kombinacja kultury, praktyk i narzędzi które łącznie przyspieszają dostarczanie klientom kolejnych wersji aplikacji i usług. W środowisku deweloperów DevOps skupia się na pojęciach takich jak budowanie kodu (ang. code building), testy pokrycia, testy jednostkowe, pakowanie i wdrażanie. W środowisku eksploatacji mówimy o aprowizacji (ang. provisioning), konfiguracji, orkiestracji i wdrażaniu. Dla obu obszarów wspólne pojęcia to zarządzanie wersjami, wdrażanie, wycofywanie zmian (ang. roll back) i testowanie.

Można powiedzieć, że o ile klasyczne metodyki zwinne dotyczą zwinności biznesowej, DevOps odnosi się do zwinności IT.


Czytaj więcej »

Tags:
Napisany w AWS, Cloud computing | Brak komentarzy »

Mikrousługi w chmurze Amazonu

Autor: Piotr Karpiuk o 17. maja 2017

Architektura mikrousług

Idea mikrousług nie powstała znikąd, obejmuje szereg sprawdzonych koncepcji takich jak programowanie zwinne (ang. agile development), architektura zorientowana na usługi (SOA), podejście API-first czy ciągłe dostarczanie (ang. continuous delivery, CD).

Główne cechy mikrousług:

  • Decentralizacja, zarówno jeśli chodzi o sposób działania (i np. spojrzenie na modele danych), ale również sposób tworzenia.
  • Niezależność – każdy komponent można zmienić niezależnie od pozostałych. Każdy komponent jest też tworzony przez osobny zespół.
  • Mikrousługa robi jedną rzecz, ale dobrze, skupiając się na jednej dziedzinie.
  • Można użyć wiele technologii – każda mikrousługa może być tworzona przy użyciu technologii najlepiej pasującej do dziedziny problemu i umiejętności zespołu.
  • Każda usługa jest czarną skrzynką z dobrze zdefiniowanym API.
  • Zespół który tworzy usługę jest odpowiedzialny za jej wdrożenie i utrzymanie – jest to jedna z najważniejszych zasad DevOps, o tyle istotna że zgodnie z prawem Conwaya architektura systemów tworzonych przez firmę odzwierciedla jej strukturę organizacyjną.

Najważniejsze zalety mikrousług:

  • Zwinność. Mikrousługi sprzyjają organizacji małych niezależnych zespołów przejmujących swoje usługi we władanie. Zespoły działają w obrębie swoich małych i dobrze zrozumiałych światów, co pozwala im skracać cykle produkcji.
  • Innowacja. Wiąże się ze swobodą wyboru technologii, języków programowania i narzędzi do tworzenia każdej usługi. Metodyki zwinne, DevOps i ciągła integracja zachęcają do eksperymentów, które można szybko przetestować i łatwo wycofać w razie niepowodzeń. Niski koszt porażki tworzy kulturę podatną na zmiany i innowacje.
  • Skalowalność i dostępność. Ponieważ mikrousługi są niezależne, można je na produkcji łatwo podmieniać i rozmnażać.

Rzecz jasna nie ma darmowych obiadów i architektura mikrousług ma również swoje wady:

  • Jest to architektura rozproszona, ze wszystkimi wadami. W szczególności nie można założyć że sieć jest niezawodna, opóźnienia komunikacji pomijalne a przepustowość interfejsów sieciowych nieskończona. Architektura mikrousług to problemy z asynchroniczną komunikacją, spójnością danych (transakcje!), odnajdywaniem się mikrousług, czy uwierzytelnianiem komunikacji.
  • Migracja. Przy przejściu z architektury monolitycznej na architekturę mikrousług trzeba podjąć właściwe decyzje dotyczące podziału – wszelkie błędy będą się później srodze mścić.
  • Wersjonowanie. W praktyce często jedna usługa będzie działać w wielu kopiach, ale w różnych wersjach. Trzeba umieć nad tym zapanować.
  • Organizacja. Skuteczne wdrożenie systemów opartych na mikrousługach wymaga często zmian organizacyjnych w firmie, która może być przystosowana do tworzenia oprogramowania w stary sposób.
  • Inne problemy. Każda mikrousługa może być tworzona przy użyciu innych technologii, ale powinien istnieć jakiś spójny mechanizm logowania czy monitorowania takiego systemu – pojawia się pytanie jak uniknąć duplikowania narzędzi i procesów, a także jak to zorganizować żeby nie poświęcać temu zbyt dużo czasu i skupić się na funkcjach biznesowych aplikacji.

Czytaj więcej »

Tags:
Napisany w AWS, Cloud computing | Brak komentarzy »

Przegląd usług AWS c.d.

Autor: Piotr Karpiuk o 14. maja 2017

Z chmury Amazonu korzysta już ponad milion aktywnych klientów. Poniżej krótki opis co ciekawszych z przeszło 100 dostępnych obecnie usług AWS. Jest to uzupełnienie wcześniejszego artykułu na ten temat.

Moc obliczeniowa

AWS Lambda
Problem z instancjami EC2 jest taki, że kosztują nawet gdy nic nie robią i dodatkowo wymagają konfiguracji i pielęgnacji (choćby np. aktualizacji systemu operacyjnego). W AWS Lambda wrzucasz kod obsługujący zdarzenia — usługa sama podejmuje wszystkie czynności niezbędne do uruchomienia i skalowania kodu, nie wykonujesz działań administracyjnych. Płacisz jedynie za czas obliczeń – w szczególności nic gdy nie ma zdarzeń do obsłużenia. Zdarzenia mogą być wyzwalane z innych usług AWS lub z Internetu/aplikacji mobilnych/urządzeń IoT itp. Większość aplikacji i usług da się zaimplementować w architekturze Lambda.
Amazon EC2 Container Registry
Rejestr obrazów Dockera.
Amazon EC2 Container Service
Usługa zarządzająca kontenerami Dockera na klastrze instancji EC2.

Pamięć masowa

Elastic File System (EFS)
Sieciowy system plików, który w przeciwieństwie do EBS może być jednocześnie współdzielony przez wiele instancji EC2 i nie wymaga rezerwacji miejsca na dysku — płacisz za dokładnie tyle miejsca ile zapisałeś, a system plików rozrasta się praktycznie w nieskończoność w miarę jak zapisujesz kolejne pliki. Przy użyciu VPNa możesz podmontować wolumen EFS do swojej lokalnej sieci i traktować jak „wirtualny dysk w chmurze” o nieograniczonej pojemności, np. na użytek backupu.
AWS Storage Gateway
Pozwala w lokalnej serwerowni podmontować zasoby S3, Glacier i EBS Amazonu za pomocą protokołów NFS i iSCSI.

Czytaj więcej »

Tags:
Napisany w AWS, Cloud computing | Brak komentarzy »

Amazon Web Services Storage

Autor: Piotr Karpiuk o 3. lutego 2015

Wybierając usługę chmury Amazona zwykle określamy region w którym ona ma fizycznie działać (USA, Brazylia, Azja, Europa), różnice cen między regionami zwykle wahają się w okolicach 10%. Każdy region jest podzielony na osobno zasilane i rozrzucone geograficznie strefy dostępności (ang. availability zones, AZ). Niektóre usługi (np. EBS – dysk sieciowy, patrz niżej, czy instancja EC2 – maszyna wirtualna) wymagają podania również strefy dostępności. Amazon ma dedykowane, szybkie połączenia sieciowe między strefami dostępności w obrębie tego samego regionu.

Propozycje Amazonu w zakresie przechowywania danych:

  • Instance storage: w wynajętej maszynie wirtualnej może być podłączony dysk SSD lub HDD o żądanej pojemności, np. instancja typu c3.8xlarge ma 2 dyski SSD po 320 GB każdy
  • Elastic Block Storage (EBS) [Cennik]: odpowiednik NASa, czyli dysk sieciowy widoczny tak samo jak dysk lokalny; jego standardowa wydajność jest słaba i wynosi ok. 100 IOPS (I/O operations per second), ale można zażyczyć sobie opcję Provisioned IOPS pozwalającą zwiększyć wydajność nawet 40-krotnie poprzez zarezerwowanie przepustowości sieci w obrębie strefy dostępności, co oczywiście dodatkowo kosztuje.
    Inne cechy EBS:
    • rozmiar jednego wolumenu waha się między 1GB a 1TB; na jednym koncie AWS można mieć max. 20 wolumenów EBS
    • cykl życia wolumenu EBS jest niezależny od instancji EC2 — można go przepinać między różnymi maszynami wirtualnymi,
    • funkcjonalność migawek (ang. snapshots) pozwala wykonać (spakowaną) migawkę zawartości wolumenu w postaci obiektu S3 (patrz dalej) a kolejne migawki mogą być przyrostowe (uwzględniają tylko zmiany od poprzedniej migawki); nowy wolumen EBS można wypełnić migawką,
    • Amazon twierdzi że każdy wolumin EBS jest duplikowany dla uchronienia się przed awarią dysku (macierz?)
  • Simple Storage Service (S3) [Cennik]: bodaj najpopularniejsza usługa Amazonu, mówi się o niej że jest magazynem Internetu (ang. the filing cabinet of the Internet), bazują na niej firmy takie jak Dropbox, Netflix czy Medcommons (ta ostatnia przechowuje w chmurze dane medyczne pacjentów). Szacuje się że 25% dużych aplikacji enterprise korzysta z S3. W ciągu ostatnich 2 lat ceny przechowywania 1 GB spadły 3-krotnie.
    • każdy obiekt ma swój klucz (łańcuch) i wartość (ciąg bajtów o wielkości od 1B do 5TB),
    • obiekty są przechowywane w wiadrach (ang. bucket, odpowiednik tabeli), jedno konto AWS może mieć max. 100 wiader; wiadro jest umiejscowione w konkretnym regionie
    • każdy obiekt S3 ma swojego URLa postaci http://s3.amazonaws.com/bucket/key, np. http://s3-us-west-1.amazonaws.com/aws4dummies/Cat+Photo.JPG i jest dostępny poprzez interfejs REST (czyli np. z przeglądarki internetowej, curl-em, itp.) o ile nadamy mu odpowiednie uprawnienia,
    • nie obsługuje modyfikacji, np. poprzez dołączenie czegoś na końcu; można tylko nadpisać obiekt nowym obiektem (można włączyć wersjonowanie, czyli dostęp do poprzednich wersji obiektu) – jest to bardzo duża różnica w porównaniu z plikiem w typowym systemie plików,
    • uprawnienia mają postać listy ACL określającej kto może wykonywać jakie operacje, klasy użytkowników to: właściciel, wskazani użytkownicy lub grupy, autoryzowani użytkownicy AWS, każdy.
    • obiekt może mieć datę ważności, po upływie której jest usuwany (stosowane np. przy wypożyczaniu filmów na określony czas), lub przenoszony do archiwum (usługa Glacier, patrz niżej),
    • obiekty mogą być szyfrowane,
    • można logować dostęp do obiektów,
    • w celu zapobiegania awariom i zwiększenia dostępności każdy obiekt jest duplikowany na kilku maszynach; można zrezygnować z tej możliwości aby zmniejszyć koszty usługi
  • DynamoDB [Cennik]: NoSQLowa baza typu key-value, odpowiednik opisanej wcześniej na blogu bazy danych Riak; korzysta z dysków SSD, dane są duplikowane w różnych strefach dostępności regionu; dostęp jest poprzez REST, lub z poziomu języków Java, .NET, Python i PHP.
  • Glacier [Cennik]: usługa backupu oparta na S3; pojedynczy plik archiwum może mieć do 40TB, dane są szyfrowane i przesyłane po SSL; zamiast wysyłać zawartość dysku po sieci, można pocztą zwykłą wysłać do Amazona fizyczny dysk – jego zawartość zostanie wrzucona do Glaciera przez pracownika Amazonu.
  • RDS [Cennik]: relacyjna baza danych (Oracle, MySQL, PostgreSQL, SQL Server, Aurora)

Zwraca się uwagę, że usługi przechowywania danych oferowane przez Amazona: DynamoDB a zwłaszcza sztandarowa S3, są świetnie przystosowane do ery BigData: nie trzeba deklarować ani rezerwować wymaganej przestrzeni dyskowej ponieważ ten sposób przechowywania danych jest wybitnie skalowalny i nie ogranicza się do pojedynczej maszyny. Redundancja w celu zapewnienia odporności na awarie pozwala nie martwić się o backupy.

Powstaje pytanie czym różni się w praktyce usługa S3 od DynamoDB. Odpowiedź na to pytanie znajdziemy w DynamoDB FAQ:

Q: When should I use Amazon DynamoDB vs Amazon S3?

A: Amazon DynamoDB stores structured data, indexed by primary key, and allows low latency read and write access to items ranging from 1 byte up to 400KB. Amazon S3 stores unstructured blobs and suited for storing large objects up to 5 TB. In order to optimize your costs across AWS services, large objects or infrequently accessed data sets should be stored in Amazon S3, while smaller data elements or file pointers (possibly to Amazon S3 objects) are best saved in Amazon DynamoDB.

Tags:
Napisany w Cloud computing | Brak komentarzy »

AWS CLI

Autor: Piotr Karpiuk o 12. stycznia 2015

AWS CLI

Wstęp

AWS CLI to interfejs wiersza poleceń do usług chmury Amazonu (Amazon Web Services, AWS). Dzięki niemu można wykonywać działania w chmurze z poziomu skryptów wiersza poleceń (Linux Bash lub Windows PowerShell). Implementacyjnie jest to skrypt Pythona, który komunikuje się z chmurą za pomocą HTTPS na porcie 443.

Instalacja

Zainstalować można na kilka sposobów:

  • z repozytorium pakietów Linuksa, np.
    apt-get install awscli

    w Ubuntu, lub jako instalator MSI w Windows (wersja 32- lub 64-bitowa)

  • za pomocą systemu pakietów Pythona, o nazwie pip: po zainstalowaniu Pythona 2.7+ lub 3.4+ oraz pip, wydajemy (z roota) polecenie:
    pip install awscli

    ewentualny upgrade wykonuje się poleceniem

    pip install --upgrade awscli
  • wykonując polecenia (Linux):
    curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
    unzip awscli-bundle.zip
    sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

Aby sprawdzić czy instalacja przebiegła poprawnie najprościej wykonać polecenie aws --version lub aws help.

Dodatkowo pod Linuksem można sobie uprzyjemnić pracę włączając autokompletowanie poleceń pod klawiszem TAB:

complete -C `which aws_completer` aws

Konfiguracja

Konfiguracja sprowadza się do wprowadzenia danych: Access Key ID i Secret Access Key, pobranych z konsoli administracyjnej AWS w przeglądarce. Dodatkowo określa się dwa parametry domyślne: region AWS oraz format wyniku polecenia. Można je przedefiniować w opcjach konkretnego polecenia (--region i --output), a region również w zmiennej środowiskowej AWS_DEFAULT_REGION.

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json

Format wynikowy to może być json (do przetwarzania wyniku programistycznie lub za pomocą procesora jq), text (do przetwarzania przez narzędzia typu sed, grep lub awk), lub table (czytelne dla ludzi).

Podane tu dane są przechowywane w plikach ~/.aws/credentials (klucze) i ~/.aws/config (domyślny region i format wynikowy).

I już możemy wykonać pierwsze polecenie AWS, opisujące nasze działające instancje w wybranym regionie:

$ aws ec2 describe-instances --output table --region us-east-1

Uwaga: Tutaj opisano konfigurację AWS CLI na komputerze znajdującym się poza chmurą (np. na prywatnym laptopie). Nieco inaczej wygląda konfiguracja na instancji EC2. Tutaj przede wszystkim instancja musi mieć przypisaną rolę z dostępem do zasobów na których chce działać (patrz dokument AWS Identity and Access Management). Po wydaniu polecenia aws configure wprowadzamy puste pola kluczy — klucze zostaną automatycznie pobrane z metadanych instancji.

Przykład: uruchamianie nowej instancji

Po pierwsze, trzeba utworzyć grupę zabezpieczeń (ang. security group), czyli odpowiednik prostego firewalla. Dodamy do niej regułę pozwalającą na dostęp do instancji przez SSH (port 22) z dowolnego miejsca na świecie:

$ aws ec2 create-security-group --group-name devenv-sg --description "security group for development environment in EC2"
$ aws ec2 authorize-security-group-ingress --group-name devenv-sg --protocol tcp --port 22 --cidr 0.0.0.0/0

Poleceniem ec2-describe-security-groups możemy pozyskać informacje o aktualnych grupach bezpieczeństwa.

Kolejnym krokiem jest utworzenie klucza do połączenia się z instancją za pomocą SSH:

$ aws ec2 create-key-pair --key-name devenv-key --query 'KeyMaterial' --output text > devenv-key.pem
$ chmod 400 devenv-key.pem

Teraz możemy już wykonać polecenie uruchomienia instancji, przy czym potrzebujemy jeszcze identyfikatora obrazu systemu operajnego (AMI). Wybierzmy obraz ami-29ebb519 (Ubuntu). Uruchomimy go na jednej z najsłabszych (i najtańszych) maszyn wirtualnych t2.micro (listę wszystkich typów instancji możemy znaleźć np. na ec2instances.info). Polecenie run-instances uruchamia instancję i zwraca JSONa opisującego uruchomioną instancję; parametr --query na tym JSONie wykonać zapytanie i zwraca jego wynik(patrz JMESPath). Poniższe polecenie zwraca identyfikator uruchomionej instancji:

$ aws ec2 run-instances --image-id ami-29ebb519 --count 1 --instance-type t2.micro --key-name devenv-key \
  --security-groups devenv-sg --query 'Instances[0].InstanceId'
"i-ec3e1e2k"

Uruchamianie chwilę potrwa (być może parę minut). Gdy już się uruchomi, możemy użyć polecenia describe-instances aby ustalić adres IP:

$ aws ec2 describe-instances --instance-ids i-ec3e1e2k --query 'Reservations[0].Instances[0].PublicIpAddress'
"54.183.22.255"

Teraz możemy już się połączyć z instancją:

$ ssh -i devenv-key.pem ubuntu@54.183.22.255

Dla Ubuntu nazwą użytkownika będzie ubuntu. Dla Fedory byłoby to fedora lub ec2-user, dla SuSe root. Ogólnie nazwa użytkownika na który należy się łączyć zależy od dostawcy obrazu systemu operacyjnego.

Lista działających instancji typu m1.small:

aws ec2 describe-instances --filters "Name=instance-type,Values=m1.small"

Terminacja (zwolnienie) instancji:

aws ec2 terminate-instances --instance-ids i-ec3e1e2k

Sposób użycia

Ogólna postać polecenia AWS CLI jest następująca:

$ aws [command] [subcommand] [parameters]

Na ogół command to nazwa usługi AWS (np. ec2 w przypadku instancji, s3 dla S3, itd.), przy wprowadzaniu subcommand warto posługiwać się klawiszem TAB, o ile włączyliśmy autokompletację (patrz wyżej).

Subcommands odpowiadają akcjom API poszczególnych usług AWS. Każda usługa ma dokumentację (ang. reference documentation), w której opisano szczegółowo wszystkie możliwe akcje wraz z parameterami, a także typy danych, możliwe komunikaty błędów itp. Patrz AWS Documentation.

Uzyskiwanie pomocy

Pomoc możemy uzyskać na trzech poziomach: głównym, usługi lub konkretnego polecenia usługi:

$ aws help
$ aws ec2 help
$ aws ec2 describe-instances help

Typy parametrów

W pomocy, opisie parametrów poleceń w nawiasach podawane są typy parametrów. Oprócz trywialnych typów takich jak String czy Integer mamy:

Timestamp
Akceptowane formaty:

2014-10-29T20:30:00.000Z
2014-10-29T12:30:00.000-08:00
2014-10-29
20141029
List
lista łańcuchów rozdzielonych spacjami
Boolean
brak takiej opcji oznacza 0, a wystąpienie 1. Na przykład opcja --dry-run.
Blob
ścieżka do lokalnego pliku, np. /tmp/image.png
Map
JSON, np. '{"id": {"N": "1"}}' lub tzw. shorthand syntax (patrz niżej).

Aby niezależnie od typu załadować wartość parametru z pliku, należy użyć URLa z przedrostkiem file:// (wspierane są skróty takie jak ~/, ./ i ../) lub http:// czy nawet https://.

Dla parametrów pobierających dane binarne należy użyć prefiksu fileb:// (np. klucze do szyfrowania).

Shorthand syntax

Shorthand syntax służy do wyrażania niezagnieżdżonych struktur, np. zamiast pisać:

--option '[value1,value2,value3]'

można tak:

--option value1 value2 value3

Z kolei zamiast:

--tags '[ {"Key": "My1stTag", "Value": "Value1" },  {"Key": "My2ndTag", "Value": "Value2" },  {"Key": "My3rdTag", "Value": "Value3" } ]'

można tak:

--tags Key=My1stTag,Value=Value1 Key=My2ndTag,Value=Value2 Key=My3rdTag,Value=Value3

Szkielety

Większość poleceń AWS CLI wspiera parametry --generate-cli-skeleton i --cli-input-json które służą odpowiednio do zapisywania parametrów w postaci JSONa i wczytywania ich z pliku zamiast wprowadzania pojedynczych parametrów w wierszu poleceń.

Wykonaj polecenie, które wygeneruje szkielet:

$ aws ec2 run-instances --generate-cli-skeleton > ec2runinst.json
$ cat ec2runinst.json
{
    "DryRun": true,
    "ImageId": "",
    "MinCount": 0,
    "MaxCount": 0,
    "KeyName": "",
    "SecurityGroups": [
        ""
    ],
    "SecurityGroupIds": [
        ""
    ],
    "UserData": "",
    "InstanceType": "",
    "Placement": {
        "AvailabilityZone": "",
        "GroupName": "",
        "Tenancy": ""
    },
    "KernelId": "",
    "RamdiskId": "",
    "BlockDeviceMappings": [
        {
            "VirtualName": "",
            "DeviceName": "",
            "Ebs": {
                "SnapshotId": "",
                "VolumeSize": 0,
                "DeleteOnTermination": true,
                "VolumeType": "",
                "Iops": 0,
                "Encrypted": true
            },
            "NoDevice": ""
        }
    ],
    "Monitoring": {
        "Enabled": true
    },
    "SubnetId": "",
    "DisableApiTermination": true,
    "InstanceInitiatedShutdownBehavior": "",
    "PrivateIpAddress": "",
    "ClientToken": "",
    "AdditionalInfo": "",
    "NetworkInterfaces": [
        {
            "NetworkInterfaceId": "",
            "DeviceIndex": 0,
            "SubnetId": "",
            "Description": "",
            "PrivateIpAddress": "",
            "Groups": [
                ""
            ],
            "DeleteOnTermination": true,
            "PrivateIpAddresses": [
                {
                    "PrivateIpAddress": "",
                    "Primary": true
                }
            ],
            "SecondaryPrivateIpAddressCount": 0,
            "AssociatePublicIpAddress": true
        }
    ],
    "IamInstanceProfile": {
        "Arn": "",
        "Name": ""
    },
    "EbsOptimized": true
}

Otwórz sobie plik ze szkieletem i dowolnie przeedytuj parametry, np. usuń te których nie potrzebujesz. Zwróć uwagę na parametr DryRun ustawiony w szablonie na true, który powoduje że polecenie wykona się „na sucho”. Gdy już będziesz pewien że wszystkie parametry masz prawidłowe możesz usunąć ten parametr aby ostatecznie wykonać polecenie.

Teraz można wykonać:

$ aws ec2 run-instances --cli-input-json file://ec2runinst.json

Tags: , , ,
Napisany w Cloud computing | Brak komentarzy »