Pracujesz sobie na systemie z bardzo okrojonymi uprawnieniami. Jesteś prawie że zwykłym użytkownikiem, zapomnij o instalacji programu tak jak należy. Z drugiej jednak strony na systemie jest zainstalowany stary program (w tym przypadku terraform), a ty chcesz używać nowszej wersji. Co zrobić?

Opcja 1

• Pobierz nową wersję programu i zapisz ją gdzie chcesz
• Uruchamiając terraforma podawaj pełną ścieżkę dostępu do tego programu (mało wygodne)

Opcja 2

• Utwórz katalog na programy, które chcesz „podmienić”
• Pobierz nową wersję programu i zapisz ją do tego katalogu
• Zmodyfikuj zmienną PATH użytkownika, tak aby wskazywała również na ten katalog
• Napisz skrypt, który będzie wywoływać właściwą wersję programu podając jego pełną ścieżkę. Zapisz skrypt w pliku o przyjemnej, krótkiej nazwie, np. tf.bat

@echo off
C:\Users\xxx\Desktop\bin\terraform.exe %*

Ten skrypt najpierw wyłącza wyświetlanie na ekran informacji o poszczególnych uruchamianych komendach, a potem wywołuje tę właściwą wersję terraforma przekazując do niego pełny zestaw argumentów %*

Dzięki temu można teraz uruchamiać najnowszą wersję programu używając wybranej krótkiej nazwy skryptu i przekazując do niego dowolne argumenty:

tf --version

Log Analytics Workspace to taki „Azurowy śmietniczek na logi”. Z jednej strony koncepcja zapisywania wszystkich logów w jednym miejscu brzmi atrakcyjnie, ale korzystanie z tagiego zbioru… delikatnie mówiąc nie jest zbyt wygodne.

Ogólnie rzecz biorąc, LogAnalytics przechowuje tabele z danymi i to już jest w sumie krok we właściwą stronę, bo jednak nasze logi są rozrzucane między wiele tabel. Tabele te powstają po podłączeniu zasobów określonych typów. Masz np. SQL Server, to pojawią sie tabele pozwalające na śledzenie specyficznych zdarzeń związanych z określonym zasobem.

Ponieważ jest tam aż tyle rzeczy, to fajnie by było sprawdzić, np. jakie wartości występują w określonej kolumnie. Zrobisz to prostym poleceniem:

AzureDiagnostics
| summarize by operationname
| order by operationname asc

Mam komputer z Windows, na którym jakiś czas temu podłączyłem się do sieci WiFi. Oczywiście podczas podłączania wprowadzałem klucz, ale… teraz go nie pamiętam. Co zrobić?

Najpierw uruchom polecenie

netsh

Teraz będąc już „w programie” netsh napisz

wlan

wlan odpowiada właśnie z wireless network czyli sieć bezprzewodową. Teraz można wyświetlić listę takich sieci uruchamiając:

show profiles

Tu powinno się udać zobaczyć nazwę sieci, dla której klucza szukamy. Zakładając że nazwa tej sieci to MYHOMEWIFI wpisz kolejne polecenie:

show profile MYHOMEWIFI key=clear

Klucz zobaczysz „czystym tekstem” w sekcji Security Settings –> Key Content. Gdyby show profile uruchomić bez opcji key=clear, to zboaczylibyśmy na ekranie w sumie te same informacje, ale z pominiętą częścią z kluczem.

Udało się? Super! Może zechcesz mi wysłać kilka drobniaków >> https://paypal.me/controlconversation ?

Visual Studio Code robi czasami psikusy ze środowiskami wirtualnymi. Jeśli instalujesz moduły, a one nadal nie działają to można podejść do sprawy tak:

– utworzyć środowisko wirtualne, co robi się komendą:

python -m venv venv

aktywować to środowisko komendą:

venv/scripts/activate.ps1

Na tym środowisku można zaintalować wymagane pakiety (zakładając że to będzie nowe środowisko, to należy zaintalować wszystkie pakiety od początku)

Kiedy to wszystko już będzie gotowe, trzeba jeszcze zadbać, żeby VSC rzeczywiście uruchamiało programy w tym środowisku wirtualnym.  Powinno wystarczyć uruchomienie Command Palette (Shift + Ctrl + P na Windows i Linux lub Shift + Cmd + P na macOS). Następnie wpisujemy/szukamy komendy „Python: Select Interpreter”. Wybieramy opcję naciskając Enter i z listy rozwijanej wybieramy Pythona z katalogu venv

Przy takiej konfiguracji wszystkie pakiety znajdują się w środowisku wirtualnym i python uruchamiający programy też będzie działać w tym samym środowisku i wszystko powinno działać.

Jak chcesz poczytać więcej o venv to zajrzyj tu: https://code.visualstudio.com/docs/python/environments

Zdarza sie, że po zainstalowaniu PostgreSQL, domyślny jezyk ustawi się np. na Polski. Mikołaj Rej by się ucieszył, ale czytanie komunikatów po polsku, jest dla mnie dość egzotyczne.

W takim przypadku można uruchomić polecenie:

SET lc_messages TO 'en_US.UTF-8′;

Można też sprawdzić jakie aktualnie onowiązują ustawnienia uruchamiając:

SELECT * FROM pg_settings where name like '%lc_%’

W kolumnie reset_value zobaczysz jednak starą wartość (u mnie „Polish_Poland.1252”), co oznacza, że po ponownym uruchomieniu serwera komunikaty znowu będą w języku Kochanowskiego. Żeby zmiana była trwała należy ją wprowadzić w pliku konfiguracyjnym postgresql.conf. Odszukaj parametru lc_messages, wpisz mu wartość:

lc_messages = 'en_US.UTF-8′

Zrestartuj usługę i gotowe!

Taki bład pojawi się, jeśli tabela wykorzystuje typ enum. Typ enum określa jakie wartości można wprowadzić do danej kolumny. Typ definiuje się np. komendą:

CREATE TYPE public.mpaa_rating AS ENUM
(’G’, 'PG’, 'PG-13′, 'R’, 'NC-17′);

Jeśli chcesz dodać kolejną dopuszczalną wartość użyj polecenia;

ALTER TYPE public.mpaa_rating ADD VALUE IF NOT EXISTS 'PG56′ AFTER 'NC-17′

Tworzenie aplikacji na Azure w postaci kodu uruchamianego „serverless” jest popularne wśród klientów. Problem tylko w tym, że zdiagnozowanie problemu może być dość kłopotliwe.

Owszem, można konfigurować application insights, które znacznie ten proces ułatwiają, ale co zrobić, jeśli klient zdecydował się nie korzystać z tej funkcjonlności? Bo za dorogo, bo nie widzi wartościw dobrym diagnozowaniu problemów? No cóż…

Mam na to swój własny sposób:

Oznaczanie uruchomienia funkcji

Funkcja może być jednocześnie uruchamiana w wielu sesjach. Jak rozpoznać logi gromadzone w LogAnalytics Workspace, żeby to wszystko się nie wymieszało? Na początku działania funkcji dodaję kod, który identyfikuje ten jeden wątek. Nie chcę przy tym, żeby był to jakiś nic-nie-znaczący UID. Chciałbym coś, co potrafię wypowiedzieć i zapamiętać. Generuję więc sobie losowy kod składający się z 6 liter, tak że pierwsza litera to spółgłoska i na zmianę występują w nim samo- i spół- głoski. Powstaje coś w rodzaju MATOKA. Napis dziwny, ale da radę go zapamiętać w skali powiedzmy 10 minut, prawda? Oto funkcja generująca taki kod w PowerShell:

# Crate ID to easier find the entries in the logs
$gr1 = "BCFFGHJKLMNPQRSRVWXZ"; 
$gr2 = "AEIOUY"
$ID = ""; 
for ($i = 0; $i -lt 3; $i++) { $ID += $gr1[(Get-Random -Maximum $gr1.Length)]; $ID += $gr2[(Get-Random -Maximum $gr2.Length)] }

Potem, gdziekolwiek w funkcji, kiedy chcę coś „zalogować” używam funkcji:

function ShowInfo{
    param(
    $ID, $MSG
    )
    Write-Output "$ID - O - $MSG"
}

Np. tak:

ShowInfo $ID "JSON INPUT: $json_input"

Wyszukiwanie logów

Szczęśliwie każda funkcja loguje do LogAnalytics Workspace. Wystarczy otworzyć dany log i uruchomić odpowiednio przygotowane wyrażenie KUSTO:

FunctionAppLogs
| where FunctionName == 'MyFunctionName'
| where Message contains "FAFOBE"
| project TimeGenerated, Message

Logi na żywo

Powyższy proces jest już całkiem ok, dla tych zdarzeń, które rzeczywiście są „zaplanowane” i „zaprogramowane”. A co jeśli dochodzi do exception, którego nie przewidzieliśmy. Jak dla mnie bardzo dobrze sprawdza się „Log stream” dostępny w konsoli Kudu. W portalu Azure w funkcji przejdź do Development Tools i wybierz Advanced Tools (oznaczony ikonką scyzoryka). Otworzy to nową stronę do konsoli Kudu właśnie, a tam u góry można znaleźć między innymi Log Stream. Kliknięcie tego linka powoduje, że zobaczysz stronę prezentującą wszystkie logi aplikacji, (te własne jak i te aplikacyjne), które będą się wyświetlać „na żywo”. Jeśli więc w programie został wyrzucony jakiś wyjątek, którego lepiej nie obsłużyliśmy, to znajdziemy go właśnie tutaj

Jeśli z kolei chcemy pogrzebać po wszystkich logach jak za dawnych czasów, to można wybrać link Bash i przejść do katalogu /home/LogFiles, a tam jest już administracyjny raj troubleshootera. Logi w plikach tekstowych, które można grepować, przeszukiwać filtrować i co tam tylko zechcesz!