Tworząc manifest terraforma, korzystasz z jakiś nazw dla zasobów. Nie tych, które zostaną użyte gdzieś tam w chmurze, tylko tych, które używamy wewnętrzenie w kodzie. Lubię myśleć o tych programistycznych nazwach zasobów, jak o zmiennych w języku programowania. Nie są to w pełni zmienne, bo zmienne definiujemy w bloku variable {}, a ja tu odnoszę się do nazw z bloku resource „” „NAME” {}

W każdym razie, wymyślając nazwy tych zmiennych pracujemy, jak programista i staramy się wymyślić coś sensownego. Po pewnym czasie może się jednak okazać, że ta nazwa zmiennej nie pasuje i trzeba by ją zmienić.

Problem w tym, że jeśli nasz manifest już był uruchomiony, to w chmurze istnieją zasoby. Uruchomienie terraform apply spowodowałoby, że rzeczywiste zasoby z chmury zostaną usunięte i utworzone na nowo, tylko dlatego, że zmieniliśmy nazwę resource w kodzie terraform.

Obejściem jest wykorzystanie polecenia terraform state mv. Może ono zmienić nazwę zasobu w state file. Dzięki temu uzyskamy zgodność między:

• kodem manifestu terraform, który korzysta z nowej nazwy
• stanem, który skojarzy rzeczywiste zasoby chmury z nowymi nazwami zasobów
• samą chmurą, gdzie zasoby już są utworzone i nie trzeba ich usuwać i tworzyć na nowo

Ogólnie rzecz biorąc przed modyfikacją state należy sporządzić kopię state file. Można to zrobić dowolną metodą, ale da się też tak:

terraform state pull > my_copy.state.file

Potem uruchamiamy

terraform state list | grep '^OLD_NAME'

To pozwoli nam zrozumieć ile zasobów musi mieć dokonane zmiany. Może to być więcej niż jeden, zwłaszcza jeśli dany zasób składa się z innych zasobów, jak np. moduł

Potem można już uruchamiać polecenie

terraform state mv 'OLD_RESOURCE_NAME' 'NEW_RESOURCE_NAME'

State mv to sprytna komenda, która na czas modyfikacji pliku state blokuje go, uniemożliwiając jednoczesna edycję przez wiele procesów, jest to więc komenda bezpieczna.

Gdyby takich zasobów do zmiany było więcej to można użyć skryptu:

for addr in $(terraform state list | grep '^OLD_NAME'); do
    new=$(echo "$addr" | sed 's/^OLD_NAME/NEW_NAME/')
    echo "Moving: $addr -> $new"
    terraform state mv "$addr" "$new"
done

Po wszystkim warto oczywiście uruchomić terraform plan. Dzięki temu przekonamy się, czy coś jeszcze zostało do zmiany

Czasami dobrze jest „zobaczyć” zależności w terraform na grafie. Można do tego wykorzystać polecenia

terraform graph > graph.dot

a potem wygenerować obraz przy pomocy dot.exe (element pakietu GraphViz)

dot.exe -Tpng graph.dot -o graph.png

Niestety to może się zakończyć błędem:

Error: graph.dot: syntax error in line 1 near ' ■d'

Problem jest w kodowaniu pliku. Można zmienić pierwsze polecenie na:

terraform graph | Out-File -Encoding ASCII graph.dot

Tutaj polecenie PowerShell Out-File zmienia kodowanie pliku na ASCII w locie i nie powinno być problemu przy uruchamianiu generowania obrazu za pomocą dot.exe

Można żyć z Pythonem w zgodnie nie znając comprehension statement, ale… może jednak warto, bo dzięki temu jest krócej, prościej, czytelniej, o ile tylko… rozumie się co to comprehension statement.

Cel jest prosty. Chcemy skrócić pętle – najlepiej do jednej linijki. No to popatrzmy na pętlę, której celem jest wygenerowanie kwadratów liczb parzystych z pewnej zadanej listy:

numbers = [1, 2, 3, 4, 5]
squares = []

for n in numbers:
    if n % 2 == 0:        # tylko liczby parzyste
        squares.append(n**2)

print(squares)  # Wynik: [4, 16]

Trzeba oczywiście zadeklarować listę numbers, potem pustą listę squares, a potem napisać for, badać parzystość przy użyciu if, podnosić do kwadratu i dodawać do listy no i na końcu wyświetlić wynik. Jest trochę długie, ale inaczej się nie da…. no właśnie stop! Comprehension skraca ten zapis do:

numbers = [1, 2, 3, 4, 5]
squares = [n**2 for n in numbers if n % 2 == 0]

print(squares)  # Wynik: [4, 16]

Ojej – ale co tu się dzieje? Oczywiście pomijamy pierwszą i ostatnią linijkę, bo one są oczywiste.

No to tak:

• Wynikiem ma być lista, a listę oznacza się w pythonie nawiasami kwadratowymi, więc mamy squares = [ coś tam ]
• Na liście mają się znaleźć kwadraty liczb, więc piszemy n**2, tylko co to jest to n?
• No właśnie n to liczby, które pochodzą z listy numbers, dodajemy więc: for n in numbers
• Ale ale! Przecież mieliśmy podnosić do kwadratu tylko liczby parzyste. No tak – dlatego dopisujemy if n % 2 == 0

W tym jednym zapisie jest cały ciąg operacji budujących pętlę for. Jest „for n in numbers”, jest „if n %2 == 0”, jest podnoszenie do kwadratu, czego ewentualnie nie ma to instrukcji append, ale ten append „dzieje się sam”, bo przecież tworząc zmienną squares napisaliśmy squares = [ …. ] czyli jest to jakiś rodzaj listy.

Comprehension można też użyć tworzyć zbiory danych, np tutaj do zbioru {} zostaną włożone wszystkie elementy z listy, a więc w efekcie nawet jeśli na liście były elementy się powtarzające, to w zbiorze będą już tylko unikalne

words = ["kot", "pies", "kot", "ryba"]
unique_lengths = {len(w) for w in words}
# Wynik: {3, 4}

To może na koniec, takie niebanalne zadanie:

Napisz pętlę, która wyświetli napis „Pan XX” lub „Pani XX” w oparciu o listę imiona. W liście imiona są zapisane imiona. Napis ma być Pan, jeśli imię kończy się spółgłoską lub Pani jeśli imię kończy się samogłoską. Skorzystaj z comprehension

imiona = ["Ala", "Ola", "Marek", "Jan", "Ewa"]

Rozwiązanie jest poniżej – scrolluj w dół:

i jeszcze

i jeszcze

i jeszcze

i jeszcze

i jeszcze

i jeszcze

i jeszcze

i jeszcze

tutaj:

wyniki = [
    ("Pani " + imie if imie[-1].lower() in "aeiouy" else "Pan " + imie)
    for imie in imiona
]

print(wyniki)
# Wynik: ['Pani Ala', 'Pani Ola', 'Pan Marek', 'Pan Jan', 'Pani Ewa']

Tzw. Logic App w Azure są dostępne w modelu „Consumption” oraz „Standard”. Zdarza się, że wydobycie informacji z logów zwłaszcza dla aplikacji „Standard” jest trudne. Oto przykład zapytania KUSTO uruchomionego w Log Analytics Workspace pozwalającego przeczytać w „wygodny” sposób, co takiego się stało. Owe „wygodny” jest w cudzysłowie, bo grzebanie w błędach absolutnie nie należy do przyjemności.

W drugiej linijce pojawia się RunId, które można znaleźć w interfejsie graficznym. Jeśli go nie znasz pomiń tą linijkę i zostaną wyświetlony wszystkie błędy ostatnio zgłoszone w aplikacji:

LogicAppWorkflowRuntime
| where RunId == "run-id"
| where Status == "Failed"
| order by TimeGenerated
| project TimeGenerated, OperationName, Code, tostring(parse_json(Error).message), ActionName

Aby zwiększyć bezpieczeństwo swojego konta, należy odpowiednio często zmieniać haslo. Zobaczmy jak to zrobić na systemie windows

Najpierw sugeruję sprawdzić swoją nazwę użytkownika:

whoami

Jeśli wynik to po prostu nazwa, to twój komputer nie jest w domenie i ważność hasła sprawdzisz poleceniem

net user twoja_nazwa

Jeśli jednak whoami zwraca wynik w postaci domena\twoja_nazwa, to korzystasz z konta domenowego i należy uruchomić

net user twoja_nazwa /domain

W obu przypadkach poszukaj pozycji „Password expires” obok której powinna być widoczna data

Linux często jest wykorzystywany do automatyzacji chmury, np. Azure. Jeśli trzeba synchronizować pliki, można użyć azcopy, ale najpierw trzeba je zainstalować. Oto jak:

Najpierw skopiuj pakiet na swój komputer (najlepiej do jakiegoś tymczasowego katalogu):

wget https://aka.ms/downloadazcopy-v10-linux -O azcopy.tar.gz

Teraz rozpakuj te pliki

tar -xf azcopy.tar.gz

Następnie skopiuj je do katalogu docelowego:

sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/

A teraz pozostaje sprawdzić, czy azcopy się uruchamia i w jakiej wersji występuje:

azcopy --version

A jeśli trzeba jeszcze zaintalować az cli to wystarczy jedno dodatkowe polecenie:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Git łącząc się do GitHub korzysta z Personal Access Token (PAT). Może zdarzyć się tak, że ten PAT chcesz albo musisz zmienić. Co wtedy?

Na Windows uruchom Credential Manager i w nim wyszukaj klucza do wymiany. Można go nawet usunąć i po prostu wprowadzić nowy.

Na Linuxie przyda się znajomość paru poleceń. Oto one:

git config --show-origin credential.helper

To polecenie sprawdzi na co wskazuje parameter credential.helper. Credential.helper (jak nazwa wskazuje) mówi o tym, kto nam pomaga w dostarczaniu credentials czyli właśnie uwierzytelnienia przed GitHub. Spodziewany wynik to:

file:.git/config        store

Znaczy to tyle, że credentials są przechowywane na dysku. Można się o tym przekonać wyświetlając plik .git-credentials:

cat ~/.git-credentials

Najprawdopodobniej zostanie wyświetlone coś w tym stylu:

https://<username>:<old_token>@github.com

No i teraz można postąpić tak, jak pod Windows, tzn. usunąć wybrany wpis lub nawet cały plik. Przy okazji wykonywania najbliższego polecenia łączącego się z GitHub zostaniemy zapytani o nowy PAT, który zapisze się w .git-credentials itp. itd….

Jeśli masz ochotę to w podobnej sytuacji można też posłużyć się poleceniem

git credential reject

To polecenie jest jednak trochę „dziwne”, bo wszystko robi „po ciuchu”. Jeśli chcesz usunąć poświadczenia do serwera GitHub – tego publicznego, a nie np. GitHub Enterprise dostępnego w twojej organizacji, to po uruchomieniu powyższego polecenia, kiedy kursor przeskoczy do kolejnej linii należy napisać:

protocol=https
host=github.com

Działa to jak zwykły „filtr” decydujący o tym co usunąć. Wszystkie wpisy w pliku .git-credentials, które rozpoczynają się od https i dotyczą serwera github.com zostaną usunięte.