Programista .NET na Linuxie cz. 2

Wprowadzenie

W poprzednim wpisie pokazałem jakiej konfiguracji, a dokładnie jakich rozszerzeń Visual Studio Code używam na co dzień tworząc aplikacje w .NET na Linux Mint. W tym wpisie pokażę kilka dodatkowych rozszerzeń do VS Code z których korzystam na co dzień i które pomagają mi w codziennej pracy. 

Thunder Client

Pierwszą z takich dodatkowych wtyczek jest Thunder Client. Bardzo prosty klient API, który jest uproszczoną wersją Postmana czy Insomni. Pozwala nam wykonywać podstawowe czynności związane z pracą z API takie jak: 

• Tworzenie i wysyłanie requestów HTTP, 
• Tworzenie kolekcji requestów 
• Obsługa parametrów i zmiennych środowiskowych 
• Możliwość tworzenia prostych testów automatyzujących nudne i powtarzalne czynności 

Dzięki tej wtyczce nie musimy się już przełączać pomiędzy aplikacjami jeśli chcemy wysłać request HTTP w celu przetestowania funkcjonalności API nad którym pracujemy. Oczywiście Thunder Client nie jest i nigdy nie będzie zamiennikiem dla Postmana czy Insomni, niemniej do podstawowej pracy z API jest moim zdaniem wystarczający. 

GIT

Kolejnym dodatkiem do VS Code, bez którego nie wyobrażam sobie pracy oprócz samego systemu kontroli wersji GIT, to rozszerzenia dla GIT takie jak GitHistory oraz GitLens. 

GitHistory

Pierwsze pozwala na wygodne przeglądanie historii i loga GIT-a, dzięki przyjemnemu interfejsowi graficznemu. 

GitLens

Drugie to prawdziwy kombajn, który przenosi pracę z GIT-em w Visual Studio Code do wyższego wymiaru. Integrując się z VS Code, dostarcza nam wiele wizualnych narzędzi pozwalających spojrzeć w najgłębsze otchłanie repozytorium, takie jak kto jest autorem danej linii kodu, kiedy ostatni raz była zmodyfikowana i link do commitu, który zawiera ostatnie zmiany powiązane z tą linią kodu oraz wiele wiele innych. 

Database Client

Czym byłoby pisanie aplikacji bez wykorzystywania baz danych? Na rynku dostępnych jest wiele klientów do popularnych silników jak SQL Server Management Studio dla MS SQL Server, pgAdmin dla Postgresa, SQL Developer dla Oracle, czy uniwersalny DBeaver. Z racji tego iż w większości te narzędzia są dedykowane dla konkretnych silników baz danych, to każde z nich oferuje dużo więcej funkcjonalności niż pisanie zapytań i przeglądanie ich zawartości. Standardem w tych narzędziach są profilery, analizatory, narzędzia do diagnostyki i zarządzania całymi stosami baz danych. 

Niemniej jeżeli potrzebujemy podstawowej funkcjonalności takiej jak pisanie zapytań i przeglądanie danych to rozszerzenie Database Client sprawdzi się znakomicie ponieważ podobnie jak w przypadku Thunder Client nie musimy mieć uruchomionej obok Visual Studio Code kolejnej aplikacji i przełączać się między nimi. 

Obecnie Database Client wspiera takie silniki baz danych jak: 

• MySql/MariaDB 
• PostgreSQL 
• SQL Server, 
• SQLite, 
• MongoDB
• Redis 
• Elastic Search 

A także pozwala łączyć się przez SSH do wspomnianych serwerów. 

Terraform

Podejście infrastruktura jako kod (ang. Infrastructure as Code) to już standard we współczesnym IT. Pisałem o tym tutaj Infrastruktura jako kod. Pomimo tego, że każdy dostawca chmurowy oferuje swoje natywne rozwiązanie do IaC takie jak Cloud Formation oraz AWS CDK dla chmury AWS, ARM Templates, Azure CLI czy Bicep dla Microsoftowej chmury Azure, to tam gdzie to możliwe moim zdaniem powinniśmy korzystać z narzędzi które są niezależne od dostawcy. Takim narzędziem niewątpliwie jest Terraform, który dla wielu inżynierów, architektów oraz firm jest już standardem. Wynika to z faktu, że możemy używać jednego narzędzia i jednego języka do pracy z wieloma chmurami.

Terraform to narzędzie konsolowe, co znaczy, że polecenia wydajemy z poziomu terminala oraz język HCL, którego używamy do opisu infrastruktury. Aby usprawnić proces pracy z Terraformem, autorzy narzędzia czyli firma Hashicorp stworzyła rozszerzenie do Visual Studio Code o nazwie Terraform. Dzięki niemu otrzymujemy w edytorze pełne wsparcie dla języka HCL oraz funkcje jak: 

• IntelliSense – automatyczne uzupełnianie nazw dostawców (ang. Providers), zasobów (ang. Resources) oraz ich atrybutów oraz źródeł danych (ang. Data Sources). 
• Sprawdzanie poprawności składni 
• Podświetlanie składni 
• Nawigacja po kodzie 
• Automatyczne formatowanie kodu 
• Snippety, czyli skróty do tworzenia bloków kodu 
• Wyświetlanie wszystkich modułów i dostawców, do których odwołuje się aktualnie otwarty plik 
• Uruchamianie poleceń bezpośrednio z palety poleceń VS Code bez potrzeby ręcznego przełączania się do terminala 

Docker

Konteneryzacja jest niewątpliwie podstawą współczesnych procesów wytwarzania oprogramowania i podstawą rozwoju podejścia cloud-native, a Docker jest wciąż numerem jeden jeśli chodzi o wybór narzędzia do konteneryzacji. Docker jak większość tego typu narzędzi jest narzędziem linii poleceń. Rozszerzenie Docker dla Visual Studio Code dostarcza wygodny UI do pracy poleceniami Docker CLI i pozwala na budowanie, zarządzanie i wdrażanie skonteneryzowanych aplikacji z poziomu Visual Studio Code. Umożliwia również debugowanie aplikacji napisanych w Node.js, Python i .NET wewnątrz działającego kontenera. 

Remote Development 

Jak już jesteśmy przy kontenerach to nie sposób nie wspomnieć o wspaniałym extension packu do Visual Studio Code, czyli VS Code Remote Development – zestawie rozszerzeń w który wchodzą takie wtyczki jak:

• Remote SSH  
• Dev Containers 
• WSL 

Remote SSH

Remote SSH pozwala podłączyć Visual Studio Code do zdalnych folderów znajdujących się na fizycznych serwerach, maszynach wirtualnych czy kontenerach. Wystarczy że zdalna usługa pozwala na dostęp przez SSH. Przykładowo dzięki temu nie musimy pobierać źródeł aplikacji na lokalną stację roboczą, możemy bez problemu uruchomić kod znajdujący się na zdalnym zasobie, korzystając z takich dobrodziejstw VS Code jak: auto-uzupełnianie, nawigacja po kodzie i debugger.

Dev Containers

Dev Containers to prawdziwy game changer w pracy z kontenerami, a zwłaszcza w pracy zespołowej, który zasługuje na osobny obszerny artykuł. Na potrzeby niniejszego artykułu napiszę tylko, że dzięki temu rozszerzeniu możemy wykorzystać Dockera do stworzenia środowiska programistycznego oddzielonego od naszego środowiska lokalnego i współdzielić z innymi osobami pracującymi przy projekcie.

Wyobraźmy sobie że dołączamy do projektu, klonujemy repozytorium i okazuje się że aby zbudować projekt musimy zainstalować wymagane zależności. Dla przykładu niech będzie to .NET Core w wersji 3.1 do backendu, jakaś specyficzna wersja Node.js i menadżer pakietów jak NPM dla aplikacji frontendowej napisanej w Angularze. Do tego dodajmy wymagane rozszerzenia VS Code do Angulara jak Angular Language Service wspierający pisanie kodu w szablonach, określony linter czy prettier do formatowania kodu. Ogólnie konfiguracja środowiska developerskiego nie należy do najciekawszych rzeczy, zwłaszcza gdy pracujemy ze starszym kodem, który wymaga konkretnych wersji środowisk uruchomieniowych i bibliotek. A co gorsza to możemy pracować na kilku projektach wymagających ich różnych wersji, co może prowadzić do konfliktów i problemów z ich kompatybilnością.

Na szczęście dzięki wykorzystaniu rozszerzenia DevContainers deklarujemy wszystkie zależności i konfigurację Visual Studio Code w plikach jak devcontainer.json, Dockerfile czy docker-compose.yml, które commitujemy do repozytorium razem z pozostałymi plikami. Po uruchomieniu tak skonfigurowanego projektu w Visual Studio Code przy użyciu rozszerzenia Dev Containers, będziemy mogli swobodnie programować z poziomu edytora bez konieczności instalacji wspomnianych zależności na lokalnym komputerze. Wszystkie zależności zostaną zainstalowane na odpowiednim kontenerze Docker oraz otrzymamy instancję Visual Studio Code z zainstalowanymi wszystkimi rozszerzeniami wymaganymi do pracy z kodem. Fajnie co?

WSL

WSL to z kolei wybawienie, gdy jestem zmuszony pracować na laptopie z Windowsem, zwykle dostarczanym przez pracodawcę lub klienta który wymaga pracy na swojej stacji roboczej będącej pod kontrolą działu IT. Dzięki WSL na stacji roboczej z systemem Windows mogę zainstalować dystrybucję Linuxa do której mogę się podłączyć z poziomu Visual Studio Code i wygodnie pracować na Linuxie. Podobnie jak w przypadku Dev Containers moja instancja VS Code zainstalowana na którejś z uruchomionych dystrybucji ma swoją specyficzną konfigurację niezależną od konfiguracji VS Code jakiej używam na Windowsie, czy innej dystrybucji, bo WSL pozwala na posiadanie zainstalowanych kilku distro obok siebie. Szczegółowe informacje na temat WSL znajdziemy w oficjalnej dokumentacji pod adresem https://learn.microsoft.com/en-us/windows/wsl/.

Kubernetes

Kubernetes podobnie jak Docker czy Terraform to jedno z najważniejszych narzędzi w podejściu cloud-native. Służy do zarządzania i orkiestracji dziesiątkami a nawet setkami kontenerów i jak większość tego typu rozwiązań jest narzędziem działającym z linii poleceń, dlatego też dla Visual Studio Code stworzono rozszerzenie Kubernetes. Dzięki niemu możemy wykonywać dużą część operacji bezpośrednio z poziomu IDE. Rozszerzenie to pozwala nam zarządzać klastrami Kubernetesa, przeglądać zasoby takie jak Namespaces, Nodes, Network, Storage czy repozytoria Helm.

Ponadto dostajemy wsparcie typu intellisense (podpowiadanie składni) w plikach zasobów Kubernetes oraz Helm chartów, dostęp do logów, snippety oraz scaffolding czyli tworzenie szkieletu plików yaml czy uruchamianie poleceń/tunelu SSH bezpośrednio w/do działających kontenerach/kontenerów.

YAML

Budując rozwiązania natywne dla chmur obliczeniowych (ang. Cloud-Native) nie sposób nie trafić i nie musieć pracować z plikami w formacie .yaml. Nie ma znaczenia czy tworzymy pliki docker-compose, pliki konfiguracyjne dla Kubernetesa czy Helm charty. YAML jest wszędzie. Wyzwaniem w pracy z YAMLem są wcięcia. Tak, YAML jest wrażliwy na wcięcia w tekście. I właśnie dlatego firma RedHat stworzyła rozszerzenie o nazwie YAML, które dostarcza wsparcia w edycji i tworzeniu plików w tym formacie. 

Podsumowanie

Visual Studio Code dzięki swojej koncepcji rozszerzeń oraz otwartości na społeczność open source sprawił, że niemożliwe stało się możliwe. Od teraz dzięki odpowiedniemu dobraniu rozszerzeń do VS Code nawet programiści .NET mogą spróbować przesiąść się z maszyn Windowsowych na Linuxy, co w dobie rozwiązań cloud-native ma jeszcze jedną zaletę – Docker na Linuxie jest natywnie wspierany (nie potrzebujemy dodatkowego hypervisora aby uruchamiać kontenery) co sprawia, że nie potrzebujemy płatnego Docker Desktop aby pracować z kontenerami.

Mam nadzieję, że ta krótka seria programisty .NET na Linuxie była dla Was wartościowa i że udało mi się Was was choć troszkę przekonać do spróbowania swoich programistycznych sił na Linuxie, nawet jeśli pracujecie z technologią od Microsoft jak .NET Core/6+