Strona główna > Azure > Azure w realnych zastosowaniach: Aktualizacja paczki produkcyjnej Cloud Service bez posiadania kodu źródłowego aplikacji czyli historia z życia wzięta na produkcji

Azure w realnych zastosowaniach: Aktualizacja paczki produkcyjnej Cloud Service bez posiadania kodu źródłowego aplikacji czyli historia z życia wzięta na produkcji

Dzisiaj to co opiszę to wyzwanie, które przytrafiło mi się kilka dni temu w mojej firmie CloudExpert.pl. Klient, który do mnie przyszedł musiał podmienić na stronie www certyfikat bezpieczeństwa SSL ponieważ wygasł, ale nie miał kodu źródłowego do rozwiązania, które miał postawione w chmurze – ot taki przypadek gdzie firma X, która to wdrożyła zdążyła się zwinąć i zniknąć zanim przekazała kod i dokumentację.

 

SIC!!

 

Rozwiązanie było wdrożone w Azure jako Cloud Service (czyli wysłane do azure w postaci paczki cspkg).

Pierwsza moja myśl była taka, że zaloguję się do portalu Azure, podmucham trochę na szczęście, wyślę nowy certyfikat, wpiszę jego Thumbprint w ustawieniach serwisu i już!!
Można by pomyśleć, że zlecenie zostanie wykonane w ciągu maksymalnie 1 godziny. Niestety naiwność jest tutaj kluczowym aspektem tej historii..

 

Podejście naiwne

 

Zrobiłem jak opisałem wyżej, dostałem od klienta nowy certyfikat w formacie pfx i hasło do niego. Wszedłem do ustawień serwisu w Azure do zakładki Certificates

image

i dodałem nowy certyfikat używając opcji Upload.

Potem na zakładce Configure podmieniłem w sekcji Certificates aktualny Thumbprint

image

 

Niestety po uruchomieniu strony strona pokazała mi cudownie czerwono, czarno, biały komunikat o błędzie web.config.

Widząc błąd web.config można było zobaczyć na moim czole lekki pot, nie dlatego, ze nie lubię plików web.config, ale dlatego, ze to oznaczało ingerencje w DEPLOYMENT paczki, do której przecież nie mamy kodu źródłowego, ba! nawet nie mamy paczki, która została wysłana kiedyś przez magicznych programistów do Azure.

Bardzo na tym etapie mnie zastanawiało dlaczego jest błąd web.config. Ale by tego się dowiedzieć potrzebuje go zobaczyć, a by go zobaczyć musze przystąpić do “poważniejszej pracy”.

i to tyle z mojego podejścia naiwnego.

 

Podejście zwane Praca Magika czyli zdobywamy paczkę

 

Mam kilka problemów startowych z dalsza praca. Po pierwsze by zmodyfikować web.config potrzebuje “poprosić” Azure o to by mi oddal paczkę, która została kiedyś przez programistów wysłana do chmury.

Po lekkim działaniu w R&D okazało się to możliwe sposobami cywilnymi czyli takimi, które nie wymagają wciągania do sprawy aspektu znajomości w firmie na M.

Pierwsza myśl naiwna trochę mogła by być taka, ze gdzieś na portalu mogę taka paczkę uzyskać, albo po prostu jest w jakims storage – ale nic bardziej mylnego. Musze do tego zaangażować tak zwane Azure Management API. Microsoft wystawia jest zarówno w formie serwisu RESTowego oraz SDK dla C#. Po lekkich bojach z REST poszedłem do sprawdzonego C# – ale i tu nie było tak prosto…

Aby moc z C# się podłączyć do Azure i wykonać tam jakakolwiek operacje musimy ściągnąć tak zwany profil publikowania z Azure, który jest plikiem zawierającym dwie bardzo ważne dla Nas informacje:

  • Subscription ID
  • Certyfikat w formie łańcucha znaków

Do dzieła – gdzie jest ten profil publikowania? Ano tutaj musimy (w sumie to nie musimy, ale nie mam pamięci do adresów URL) zaangażować PowerShell i to nie byle jaki bo Azure PowerShell

image

w ktorym wpisujemy komende

image

wtedy uruchamia sie okno przegladarki internetowej z logowaniem do konta Azure:

image

Po zalogowaniu ukazuje się okno z wyborem subskrypcji – wybieramy, potwierdzamy i czekamy aż ściągnie się plik na Nasz dysk.

image

i mamy to czego potrzebujemy – sekcja ID i sekcja ManagementCertificate to to czego szukaliśmy!.

Odpalamy Visual Studio, tworzymy projekt w C# aplikacji konsolowej i przechodzimy do instalowania paczki NuGET i instalujemy to co zaznaczyłem

image

przystępujemy do programowania

image

Powyższy napisany kod wymaga głębszego wyjaśnienia.

Metoda startowa Main odpala metodę w klasie statycznej, która napisałem po to by odwołać się do Azure. Ta metoda według mnie nie wymaga wyjaśnień.

To co wymaga wyjaśnień to kod metody Metoda(). Zaczynamy w niej od inicjalizacji klasy X509…, która będzie przechowywała Nasz certyfikat. Do tej zmiennej kopiujemy jako zawartość w miejsce XXX_… ciąg znaków z pliku publikowania, który przed chwila ściągnęliśmy. Certyfikat jest potrzebny do autentykacji w Azure Naszej aplikacji.

Dalej inicjalizujemy dostęp do subskrypcji podając certyfikat i subscription id, który tez mamy z pliku.

Kolejny krok to utworzenie klienta, który pozwoli “rozmawiać” z mechanizmem w Azure odpowiedzialnym za zarzadzanie serwisami z maszynami wirtualnymi (Cloud Services) – wystarczy mu podać zmienna dostępowa do subskrypcji.

Kluczowa dla Naszej operacji jest metoda BeginGettingPackageByNameAsync. To ta metoda będzie w stanie wydobyć paczkę z Azure. Ma ona jeden mankament, nie pozwala sciagnac paczki bezpośrednio, a wysłać ja na storage Azure’owy. To pociąga za sobą to ze musimy stworzyć storage w ramach Naszej subskrypcji, stworzyć tam Public lub Private Container i adres całości wkleić w miejsce adresu do Azure Storage w moim kodzie powyżej.

Niewyjaśnione są jeszcze dwa wcześniejsze parametry. Aby moc je wyjaśnić musimy przejść do Naszego Cloud serwis w portalu Azure’owym, kliknąć w niego i przejść na zakładkę Dashboard:

  • Nazwa, która widzimy w nagłówku to nazwa do wklejenia w NazwaSerwisu
  • Po lewej stronie przesuwając stronę w dol. znajdziemy pole Deployment Name i wklejamy w kolejna zmienna.
  • Po uruchomieniu aplikacji Nasza paczka na pewno będzie już na storage.

image

    Paczka nie będzie tam sama, dodatkowo Azure skopiuje do pliku konfiguracje tak zwany CSDEF, która Nam się przyda przy wgrywaniu Nowej paczki do Azure.

Kolejny krok to ściągniecie paczki na komputer, ja używam do tego narzędzia Azure Storage Explorer (https://azurestorageexplorer.codeplex.com/) – wchodzę do narzędzia, dodaje nowe konto, podaje nazwę storage i klucz dostępowy API. Przechodzimy do katalogu, w którym jest paczka i ściągamy plik CSPKG – na pewno ma wiele megabajtów.

 

Naiwności cześć druga – czyli rozłupujemy paczkę

 

Na szkoleniach opowiadam czasami o tym, ze paczka, ktora tworzy Visual Studio to plik ZIP. Nie klamie, to plik zip tylko z innym rozszerzeniem, dlatego pierwsze co robie, to zmieniam rozszerzenie pliku na ZIP i rozpakowuje.

Po rozpakowaniu widzę cos takiego:

image

widzę kilka dziwnych plików i jeden bardzo duży plik. Szukam ogólnie plików DLL i stron ASPX i nigdzie nie widzę – ciągle interesuje mnie ten plik CSSX…

…ryzykuje, zmieniam mu rozszerzenie na ZIP i próbuje rozpakować – BINGO – działa, to tez był ZIP.

Zawartość wygląda mniej więcej tak:

image

chodzę nerwowo po katalogach i BINGO po raz drugi, widzę w approot aplikacje! Myślę sobie jestem uratowany.

Szukam pliku web.config, przez który w ogóle się w to wszystko bawimy i widzę co jest nie tak:

image

Ktoś używa starego certyfikatu do usługi Microsoft Identity… myślę sobie tragedia, ale z drugiej strony podmienię zawartość Thumbprint i po sprawie.

Tak robię – podmieniam.

Nie zastanawiam się długo co zrobić dalej, przechodzę katalog wyżej, pakuje to wszystko do formatu ZIP i zmieniam rozszerzenie do CSSX, usuwam stary plik CSSX, a nowy nazywam tak samo jak stary i wkładam do pierwszego rozpakowanego katalogu. Kolejna operacja wydaje się być oczywista, pakuje całość do ZIP i zmieniam rozszerzenie na CSPKG.

Wchodze na portal, klikam w Cloud Service, wybieram Dashboard i klikam na belce dolnej UPDATE.

image

Teraz wszystko wydaje się znowu proste, wybieram w sekcji package FROM LOCAL i wybieram nowy plik CSPKG, a w konfiguracji wybieram FROM STORAGE i szukam chwile po storage gdzie jest plik, który sam Azure włożył mi na storage i działam! Daje OK i czekam i czekam i czekam i czekam… i po chwili EXCEPTION – BAD Argument. Try again. Myślicie, ze nie próbowałem? Z kilka razy. Poddałem się, nie działa.
Finalnie paczka nie zadziałała ponieważ Azure uznał, ze ktoś naruszył jej integralność, sumy kontrolne poukrywane w plikach się nie zgadzały i finalnie nie zadziałało.

 

Mierzymy siły na zamiary

 

Myślę myślę myślę i mam. Spróbuje przekonwertować paczkę na inny format, może w innym formacie da się edytować paczkę – skąd wiem o innym formacie? Słyszałem, ze są co najmniej dwa formaty tworzenia paczek do Azure. Skoro moja paczka jest w formacie X, to może format Y będzie edytowalny. Odpalam na razie CSPACK, które zajmuje się tworzeniem paczek w konsoli. Na razie znajdziemy jak uruchomimy konsole Azure CMD

image

jak wpiszemy CSPACK i damy enter to zobaczymy liste opcji. W opcjach jest m.in

image

wpisuje komendę

image

i błąd! cóż za załamanie… !!!!

Ale nie poddaje się i pobieram SDK 1.8 z strony Microsoft Azure – wersja z 2012 roku. Co za czasy…

Po zainstalowaniu uruchamiam konsole CMD dla Azure SDK w wersji 1.8 i widzę takie cos:

 

image

wpisuje komendę i

image

nie ma błędu, ale tez nie wiadomo czy działa. Faktycznie widzę na pulpicie nowy plik choć jest o polowe mniejszy, poprzedni ma 44 MB, a ten ma 21 MB. Dziwne.

Zmieniam rozszerzenie pliku NOWY.CSPKG na NOWY.ZIP i rozpakowuje i co za niespodzianka…

image

Chodzę po katalogach i brak moich plików, same dziwne pliki, np: jest tu katalog który ma tysiące plików bez rozszerzenia

image

i tym katalogiem zainteresowałem się bliżej, bo klikając na dowolny plik i otwierając go w notatniku zacząłem widzieć pliki ASPX, DLLki… czyli jakby ktoś wszystkim plikom odebrał nazwę i rozszerzenie i włożył w plaska strukturę do jednego katalogu…

Skoro tak, to gdzieś musi być spis tych plików – i faktycznie jest, jest to pik package.xml – o jeden stopień wyżej w hierarchii katalogów.

Wszedłem do pliku package.xml i zacząłem szukać web.config

image

i faktycznie był, tu tez dowiedziałem się ze web.config to tak na prawdę LocalContent/e923bf66c1114dc0b7d6888f13d6bd01 – znalazłem plik i podmieniłem mu zawartość na właściwa – w końcu to mój poszukiwany web.config

Teraz najgorszy moment, spakowalem calosc do pliku ZIP i nadalem rozszerzenie CSPKG – dalej nie wiem czemu zawartosc jest dwa razy mniejsza niz oryginal ale na razie ignoruje ten fakt. Zastanawiam sie czy portal Azure’owy rozumie ten format paczek, bo to moja jedyna przeszkoda teraz – ale co tam, ryzykuje. Wchodze jeszcze raz do okna UPDATE

image

i jak wyżej już opisywałem robię identycznie. Dodaje plik cspkg z dysku lokalnego, a plik z konfiguracja z Storage. Czekam czekam czekam… i czekam i czekam i czekam… i czekam i czekam i czekam… Widzę komunikat i nie wierze, komunikat

Completed!

 

Podsumowanie

 

Zycie pisze różne scenariusze. Siedzę w Azure już od 6 lat, widziałem sporo, wiem sporo – ale ten przypadek był bardzo ciekawy i powiem szczerze pierwszy takiego rodzaju. Klient z portalem, którego nie ma w postaci kodu, nie da się go zbudować, nie ma tez paczki i należy zaingerować w paczkę i zaktualizować portal.

To był bardzo ciekawy przypadek, intelektualnie wyczerpujący, ale ciekawy. Więcej proszę!

Kategorie:Azure
  1. Brak komentarzy.
  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d blogerów lubi to: