Domyślnie komendy i podkomendy dla terraforma trzeba znać, ale… można też pozwolić nauczyć się ich shellowi BASH (co dotyczy oczywiście tylko tych użytkowników, którzy pracują z BASHem).
Wystarczy wpisać polecenie:
terraform --install-autocomplete
Po tej komendzie wymagany jest restart shell-a lub ponowne wczytanie profilu, a potem…. po wpisaniu komendy terraform można nacisnąć tabulator raz lub dwa razy i zobaczysz podpowiedź, co można w swoim poleceniu napisać dalej:
AZ-104 to pierwszy profesjonalny egzamin na drodze administratora i architekta Azure. Ma on opinię dość ciężkiego egzaminu, bo pytania dotyczą szerokiego zakresu wiedzy, a tytuł administratora Azure, który zdobywa się po tym egzaminie zobowiązuje do dość szczegółowej wiedzy.
Dla wszystkich kandydatów przygotowaliśmy już drugi kurs przygotowujący: „AZ-104 Administrator Azure – Identity & Governance„.
Główne tematy kursu to:
Drugi kurs, a właściwie pierwszy, bo był wydany wcześniej to „AZ-104 Administrator Azure – Storage„.
Łącznie oba kursy pokrywają już ponad 60% materiału wymaganego do opanowania na egzamin. Wszystko z licznymi przykładami, testami, po polsku i z nutką humoru.
Zapraszamy!
Chcesz skonfigurować drukarkę, żeby automatycznie wysyłała faksy? A może chcesz codziennie dostać na maila raport o ilości wolnego dysku na domowym serwerze? A może po prostu chcesz z poziomu programu, czy skryptu wysłać sobie maila? W takim przypadku musisz skonfigurować, drukarkę, czy skrypt do korzystania z serwera SMTP. Jest jednak drobny problem. Ileś tam lat temu, żeby wysłać maila wystarczyło znać nazwę użytkownika i hasło i było to mocno wykorzystywane przez spamerów. Dlatego konfiguracja SMTP jest chyba obecnie jedną z najcięższych dla administratora, a i dla programisty wiele się zmieniło. Jeśli chcesz użyć SMTP programistycznie musisz wygenerować sobie odpowiedni token, tzw. application password. Tutaj pokażę, jak to zrobić z kontem GMAIL.
import smtplib
mailFrom = 'Your automation system'
mailTo = ['XXX@wp.pl','YYY@gmail.com']
mailSubject = 'Processing finished successfully'
mailBody = '''Hello
This mail confirms that processing has finished without problems,
Have a nice day!'''
message = '''From: {}
Subject: {}
{}
'''.format(mailFrom, mailSubject, mailBody)
user = 'my_user@gmail.com'
password = '***********'
server = smtplib.SMTP_SSL('smtp.gmail.com', 465)
server.ehlo()
server.login(user,password)
server.sendmail(user, mailTo, message)
server.close()
print('mail sent')W Azure mamy dwa rodzaje logic apps: consumption i standard. Z zewnątrz oba wyglądają podobnie, bo i nazwa taka sama i sposób budowy aplikacji podobny, więc w czym problem?
Otóż okazuje sie, że wewnętrzenie te dwa modele logic app to coś zupełnie innego. O ile consumption to rzeczywiście usługa serverless, już wstępnie skonfigurowana i z tonami dokumentacji, o tyle standard jest właściwie aplikacją webową z przydzielonymi zasobami compute i wymaga dodatkowej konfiguracji niemal na każdym kroku, tymczasem z dokumentacją jest…. tak jakby nieco gorzej.
Jeden z problemów polega na tym, że logic app standard workflow stateless nie posiada historii! Nie widać kiedy się uruchomił workflow i co robił, kiedy już się go udało uruchomić.
Jest na to rozwiązanie wskazane o tutaj: https://learn.microsoft.com/en-us/azure/logic-apps/create-single-tenant-workflows-azure-portal#enable-run-history-for-stateless-workflows
W settings >> configuration należy samodzielnie dodać nowe ustawienie o nazwie:
Workflows.<nazwa_workflow>.OperationOptions
a w jej wartości wprowadzić tekst:
WithStatelessRunHistory
Zapisanie zmian spowoduje restart aplikacji, ale co tam – dzięki temu będzie widać co się działo z aplikacją!
Debugowanie aplikacji, czy skryptu z wykorzystaniem lokalnie instalowanych narzędzi to … przyjemność. Co jednak zrobić jeśli zdebugować trzeba nieco dziwne Logic Apps?
Oto propozycja.
Funkcje, czyli z grubsza rzecz biorąc, główni reprezentanci linii serverless w Azure (FunctionApp i LogicApp) mogą łączyć się z siecią w trzech płaszczyznach:
Integration subnet nigdy nie jest wykorzystywane do połączenia się do funkcji. Nawet jeśli do integration subnet podłączysz NSG z regułami inbound, to zostaną one zignorowane, bo ruch przychodzący po prostu nie działa. Jedynym wyjątkiem są pakiety transferowane w ramach odpowiedzi na komunikację wychodzącą z funkcji, ale to zrozumiałe, bo bez tego komunikacja nie miałaby sensu.
Dzięki sprytnemu połączeniu ręcznie konfigurowanego routingu, NSG, integracji z Firewallem i innych mechanizmów konfiguracji sieci, administrator ma szeroki zakres możliwości definiowania jakie połączenia mogą być nawiązywane przez funkcje, np.: korzystanie z zasobów lokalnych sieci, połączenie do on-prem, połączenia z express route, innymi endpointami, wyjście do Internetu itd.
Do wykonania konfiguracji NSG może się przydać znajomość prywatnego adresu IP funkcji w integration subnet. Jest on zapisany w zmiennej środowiskowej WEBSITE_PRIVATE_IP.
Ruch sieciowy generowany przez funkcję podlega normalnym regułom. Jeśli np. chcesz przesłać pakiety do gateway’a, wystarczy odpowiednio zmodyfikować trasy routingu przypisane do podsieci.
Co ciekawe, application plan bazujący na windows, może się integrować z dwiema podsieciami, a na linux, tylko z jedną.
Sam routing to również ciekawa sprawa, bo można go konfigurować w trzech zakresach:
Z drugiej strony private endpoint, pozwala na połączenie się do usługi. Endpoint jest podłączony do wybranej podsieci, otrzymuje swój adres IP, a ten adres powinien być zarejestrowany w DNS. Dzięki temu wybrane usługi będą mogły połączyć się do funkcji i skorzystać z jej funkcjonalności.
Integrate your app with an Azure virtual network – Azure App Service | Microsoft Learn
Opss. terraform się wywalił i w efekcie, część zasobów została utworzona w Azure, ale plik stanu nie został zaktualizowany. W takim przypadku otrzymsz błąd:
Error: A resource with the ID „/subscriptions/XXXX/resourceGroups/RG-TerraformLab/providers/Microsoft.Network/virtualNetworks/KRK-VNET/subnets/dev_subnet” already exists – to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for „azurerm_subnet_network_security_group_association” for more information.
No tak, to problemy mam dwa: 1 – zaimportowanie obiektu tworzonego przez for_each i 2 – próbuję utworzyć zasób azurerm_subnet_network_security_group_association, tymczasem brakujący obiekt to po prostu azurerm_subnet.
Na szczęście komunikat o błędzie zawiera już prawie wszystko, co trzeba. Rzeczywiście polecenie import oczekuje dwóch parameterów. Nazwy zasobu tak jak jest ona zdefiniowana dla Azure oraz identyfikatora zasobu. Na dodatek, to właśnie obiekt subnet zawiera w sobie informacje o association, więc w sumie, to problemu nie ma. No to jedziemy:
terraform import azurerm_subnet_network_security_group_association.sub_nsg["dev_subnet"] /subscriptions/XXXX/resourceGroups/RG-TerraformLab/providers/Microsoft.Network/virtualNetworks/KRK-VNET/subnets/dev_subnet
Niestety – komenda u mnie nie działa dobrze:
Index brackets must contain either a literal number or a literal string.
No jak to!? Przecież mam „literal string”. O co chodzi? Chodzi o to, że jestem fanem powershella i pracuję w powershellu. Tutaj poprawna komenda to:
terraform import azurerm_subnet_network_security_group_association.sub_nsg[\`"dev_subnet\`"] /subscriptions/XXXX/resourceGroups/RG-TerraformLab/providers/Microsoft.Network/virtualNetworks/KRK-VNET/subnets/dev_subnet
Uff – udało się!
