Automatyzacja procesu budowania aplikacji .NET Core w Visual Studio, utrzymywanego na serwerze pod Ubuntu

0

Witam,

Od kilku miesięcy uczę się .NET'a, a od tygodnia .NET Core'a.

Mój cel to działając z poziomu Windowsa (bo tu działa VS 2017) automatycznie przesyłać pliki projektu na serwer działający w Linuxie (u mnie Ubuntu), żeby tam się robił Release (rozumiem, że wypuszczanie projektu na serwer Ubuntu nie może się odbywać z poziomu środowiska Windows, gdyż brakuje wtedy katalogu publish w folderze netcoreapp2.0)

Do tej pory udało mi się zainstalować w Virtual Box'ie Ubuntu 16 server (jako symulacje zewnętrznego serwera), oraz za pomocą Nginx'a postawić na nim przykładowy (domyślny) projekt .NET Core. Wszystko wykonuje z poziomu Windowsa:

  • Tworze nowy projekt w VS 2017,
  • Release projektu na Linux'ie wykonuję za pomocą PuTTy,
  • Po wpisaniu adresu maszyny wirtualnej w Chromie przeglądam działającą aplikację,
    Więc cel jest spełniony połowicznie, mogę wszystko wykonywać ręcznie.

Pytanie jest takie: Czy w VS 2017 Community lub .NET Core istnieje możliwość automatyzacji tego procesu, czy może jest to możliwe za pomocą jakiś dodatkowych narzędzi |(np. Docker, Cake, Buddy?). Być może rozwiązanie jest łatwe, ale jeszcze go nie widzę przez zbyt małe doświadczenie (jeszcze dwa tygodnie temu nie widziałem nic o Linuxie czy Nginx).

Jeśli wystarczająco jasno opisałem problem i da się zrozumieć o co mi chodzi to proszę o pomoc (do tej pory, nie korzystałem z forów, odpowiedzi na wszystkie problemy znajdowałem w sieci).

Pozdrawiam,

2

Jest wiele możliwości. Do budowania projektu to: Jenkins, TeamCity itd. Do procesu deployu Octopus ,ale może to być też skrypt w powershellu czy bashu. Możesz także użyć dockera i publikować obraz np. na Docker-Hubie, a pobierać i stawiać kontener automatycznie poprzez Ranchera. O całym procesie możesz poczytać wpisując w google "Continous Integration + .Net Core"

1

rozumiem, że wypuszczanie projektu na serwer Ubuntu nie może się odbywać z poziomu środowiska Windows, gdyż brakuje wtedy katalogu publish w folderze netcoreapp2.0

Źle rozumiesz. Komenda dotnet publish generuje ci właśnie folder "publish", który kopiujesz na Ubuntu i on tam po prostu działa. Ja mam mniej więcej taką konfigurację w jednym z projektów - jest sobie skrypt, który robi właśnie dotnet publish, pakuje wszystko do pliku tar.gz, a potem ten tar.gz wysyła na serwer Linuksowy.

Jeżeli używasz gita to można też użyć git hooks i pushować do repozytorium na serwerze, a on sobie sam weźmie, zbuduje i uruchomi zaktualizowaną wersję.

0

Dzięki za odpowiedź.

Czy da się zrobić jakoś "dotnet publish" z poziomu VS ewentualnie z poziomu Windowsa? Sprawdzałem opcje gdy klikam na publikuj:

  • folder - Wprawdzie tworzy się plik publish, ale gdy chciałem w Ngin'x dodać do niego konfiguracje to wyskakuje taki błąd w konsoli Ubuntu: Nie można połączyć się z Usługą Upstart: Failed to connect to socket /com/ubuntu/upstart: Połączenie odrzucone. Z tego co czytałem w sieci dowiedziałem się, że Ubuntu przeszło z Upstart na systemd. Pewnie gdybym w linuxie zrobił komendę publish, to tego problemu by nie było, ale, że publikowanie jest z pozimu Windowsa, to może odnosić się do Upstart a nie do systemd (gdzie konfiguruje kernel-nazwa.service dla Ngin'x). Pytanie jest czy da się to jakoś naprawić np doinstalowując coś w Linuxie,
  • IIS - Rozumiem, że to jest dla Windowsa i na Linuxie nie można opublikować strony przy pomocy Web Deploy,
  • Inne profile są głównie związane z Azure,
0

Powinno być pomocne:

  1. Link1
  2. Link2
  3. Link3
0

folder - Wprawdzie tworzy się plik publish, ale gdy chciałem w Ngin'x dodać do niego konfiguracje to wyskakuje taki błąd w konsoli Ubuntu: Nie można połączyć się z Usługą Upstart: (...)

Pokaż swój plik .service, bo coś z nim jest raczej nie tak. publish w ogóle nie generuje pliku usługi, więc nie wiem jaki to ma związek.

0

Dzięki za odpowiedź, już naprawiłem problem. Do tej pory działałem lokalnie i sporo zrozumiałem. Teraz kolejny krok czyli zbudowanie modelu zdalnego, tu przydadzą się linki które froziu podesłał. Dzięki.

0

Aha zapomniałem. Jeszcze jedna rzecz się pojawia. Czy jest jakaś opcja debuggowania w środowisku Linux'a z poziomu VS? Wiem, że to możliwe dla "Linux Development with C++" ( https://docs.microsoft.com/en-us/cpp/linux/deploy-run-and-debug-your-linux-project ), ale czy dla aplikacji .NET Core też tak można? Innymi słowy czy da się zrobić deploy aplikacji.NET Core z VS w Windowsie na Serwer pod Ubuntu postawiony w VB?

0

Da się, poprzez SSH: https://blogs.msdn.microsoft.com/devops/2017/01/26/debugging-net-core-on-unix-over-ssh/

Aczkolwiek kiedy to robiłem to musiałem zmusić moją aplikację, aby uruchomiła się na użytkowniku do którego mam dostęp przez SSH, a nie na jego (np. http), bo nie chciał się podłączyć do procesu. Pewnie się to da jakoś obejść, ale nie miałem czasu.

0

Cenna podpowiedź, dzięki.

Ja próbuje się przegryźć przez:
https://docs.microsoft.com/en-US/visualstudio/debugger/remote-debugging-csharp
https://docs.microsoft.com/en-US/visualstudio/debugger/remote-debugging-aspnet-on-a-remote-iis-computer
Ale tam nie ma rozwiązań dla Linux'a. Więc, chyba mnie ustrzegłeś przed niepotrzebnym analizowaniem tych materiałów.

Co do artykułu to wcześniej w opcje -> wiele platform udało mi się dodać moją maszynę Ubuntu z VB. A teraz po kliknięciu w przycisk "Dołącz" widzę ją po wybraniu typ połączenia -> SSH :) (nie widzę co prawda w dostępnych procesach dotnetu, ale powinienem sobie z tym poradzić, najważniejsze, że jest progres :)

Jak mi się uda zdebugować projekt i obejść to o czym pisałeś, to postaram się też tu tym podzielić :)

0

No właśnie jak nie widzisz w procesach procesu dotnet, to dlatego, że twoja aplikacja działa na innym użytkowniku. Tam się gdzieś klika, aby zobaczyć procesy wszystkich użytkowników, ale nie wiem jak mu pozwolić na połączenie się do cudzego procesu - nie wiem czy w ogóle Linux pozwala na takie cuda.

Alternatywą było by uruchomienie debugera jako superuser, ale tego też nie wiedziałem jak zrobić - łatwiej mi było przerobić plik .service, aby usługa działała na moim koncie dopóki nie przetestowałem jej dogłębnie.

1

Udało się. Dzięki.

Błędy po drodze:

  • sudo -u username dotnet run - zmuszenie systemu Linux do tego, żeby odpalił proces na koncie z dostępem do SSH nie chciało nawet ruszyć
  • dotnet run (bez sudo) - nie chciało nawet ruszyć
  • sudo dotnet run - proces ruszał na użytkowniku root, VS widział ten proces, ale podłączenie kończyło się błędem. "no process with the specified ID is currlenty running"

Rozwiązanie:
Kompilacja projektu (czy to w VS, czy to poprzez dotnet build), i opalenie dll poprzez komendę dotnet nazwaaplikacji.dll, wtedy proces ruszał na użytkowniku z dostępem do SSH i debuggowanie stało się możliwe :)

0

Witam,

Pojawił się kolejny błąd przy zdalnym debuggowaniu na maszynie pod Ubuntu Serwer, gdy odpalam dotnet nazwaaplikacji.dll to wyskakuje taki błąd:

screenshot-20180323130958.png

Po przebudowaniu projektu komendą dotnet build, wszystko działa, ale w oryginalnym projekcie w VS pojawia się:

screenshot-20180323131210.png

Pojawia się także mnóstwo podkreśleń w kodzie. Gdy probuję podłączyć proces za pomocą debuguj -> podłącz to wszystko jest ok, ale gdy odpalam w przeglądarce po Windowsem adres serwera to wyskakuje:

screenshot-20180323131513.png

Mogę oczywiście skompilować ponownie projekt ponownie w VS, a wtedy sytuacja wygląd atak:

screenshot-20180323131550.png

No, ale wtedy wracamy do błędu przedstawionego na początku. Sytuacja wygląda tak, jakby Windows z Linuxem po zbudowaniu aplikacji wzajemnie się zwalczali, po przebudowaniu w Windowsie, jest ok w Windowsie, a po przebudowaniu w Linuxie, jest ok w Linuxie. Szukałem odpowiedzi na ten problem, ale stosowane rozwiązania nie pomagają.

Pozdrawiam,

PS:
Udało mi się ustalić, że debuggowanie co prawda zachodzi, ale nie znaleziono odpowiedniego widoku, którego rządam: (to samo z widokiem Error, Chart, itp...)
screenshot-20180323143608.png
Mam w kontrolerze metodę GetJson, gdy wpisuje w pasek przeglądarki Home/GetJeson, to ładnie debugger wychwytuje operację. Więc problem sprowadza się do tego dlaczego podczas zdalnego debugowania nie można znaleźć widoku, który na pewno jest (gdyż w samym VS wszystko ładnie działa).

1

Witam,

Udało mi się rozwiązać problem. Dla przyszłych pokoleń zamieszczam rozwiązanie :)

  1. Tutaj najbardziej interesujące linki o tym problemie:
  1. Co zadziałało u mnie:
  • Z poziomu Linuxa wykonać komendę dotnet publish, (a nie samo dotnet build - to jest nawet niewskazane, ponieważ tak jak pisałem wyżej, w VS pojawiało się wtedy pełno błędów i trzeba było ponownie kompilować projekt),
  • Z poziomu Linuxa wejść do filderu bin/debug/netcoreapp2.0/publish i tu odpalić dotnet naszaaplikacja.dll
  • Z poziomu VS dołączyć proces (jak to było opisane powyżej),

Pozdrawiam,

0

Im dalej w las tym więcej drzew. Zdalne debuggowanie działa. Jednak teraz pojawia się kolejna kwestia, jak uwzględnić w tym bazę danych (np. PostgreSQL, który potrzebuje do działania własnego serwera o porcie domyslnym 5432).

Aplikacja uruchamiana w Windowskie z poziomu VS działa. ale Przy próbie zdalnego debuggowania pojawia się (w momencie odwołania się do bazy danych):

screenshot-20180406125933.png

Mam świadomość, że chciałem wybrać drogę na skróty, czy ktoś wie jak zdalnie debuggować aplikację, która łączy się z baza danych taką jak PostreSQL?

Pozdrawaim,

0

Nie rozumiem chyba. Co ten Postgres ma do rzeczy w debugu? Zdalna aplikacja rzuca ci tutaj oczywisty wyjątek - nie może połączyć się z bazą. Czy debugujesz ją zdalnie przez VS czy uruchomisz przez dotnet run czy jakkkolwiek nie ma kompletnie znaczenia.
Ja przepraszam, że pytam o rzeczy oczywiste - ale na tym serwerze na którym masz aplikację masz działający Postgres nasłuchujący na localhost na porcie 5432 i on na pewno działa?

Co z tego, że w twoim VS działa, jak przecież ona łączy się do localhost, a lokalnie localhost to przecież kompletnie co innego niż localhost na zdalnej maszynie.

0

Rozumiem, że się nie da tego zdalnie debuggować w ten sposób. To może inne pytanie zadam, jak "przerzucić" bazę danych, aby zdalny serwer (w tym przypadku Ubuntu w VirtualBoxie) mógł się z ta bazą łączyć i żeby można z poziomu Windowsa za pomocą np RESTlet Clienta wykonywać polecenia GET, POST itp..?

1

Musisz mieć połączenie sieciowe które jest pomiędzy VirtualBoxem i twoją maszyną-hostem. Spróbuj tego: https://www.thomas-krenn.com/pl/wiki/Konfiguracja_sieciowa_w_VirtualBox#Karta_sieci_izolowanej_.28host-only.29

Potem musisz zmusić swojego Postgresa/swoją aplikację, aby nasłuchiwały również na tym połączeniu sieciowym (a nie tylko 127.0.0.1), aby mogły się nawzajem połączyć.

0

Bardzo wartościowa odpowiedź. Dzięki. A to mam jeszcze jedno pytanko. Zauważyłem, że PostreSQL ma taką opcje jak dump bazy danych. Czy w takim razie można całkowicie "zrzucić" aplikację wraz z bazą danych z Windowsa na Serwer Ubuntu (niekoniecznie w VirtualBox'ie, tu możemy mówić o jakiejś innej maszynie która działa non-stop), żeby aplikacja była dostępna dla innych?
Inbnymi słowy:
Aplikacja: Windows ----- dotnet publish --> Ubuntu Serwer
Baza danych: Windows ----- dump --> Ubuntu Serwer
I w ten sposób aplikacja sobie działa :)

0

Tak, oczywiście. To dość typowe postępowanie. Musisz tylko pamiętać o utrzymywaniu struktury bazy danych, aby była zgodna na maszynie na której uruchamiasz wersję produkcyjną i wersję testową (i pamiętać o przenoszeniu kluczowych danych, jeśli takie masz).

0

Baza danych w Windowsie jest tworzona poprzez migracje z poziomu CLI. A czy w takim razie możliwe jest zrobienie migracji poprzez CLI w Ubuntu jeśli:

  • na Ubuntu jest zainstalowany serwer ProstreSQL,
  • nie zależy mi na przenoszeniu testowych danych,
  • na serwerze Ubuntu jest nie tylko "publish" projektu, ale i cały projekt,
    ?
    Pozdrawiam,
0

Witam,

W sumie to sobie sam odpowiedziałem na powyższe pytanie: można. Mając cały projekt można na Ubuntu odpalić dotnet ef database update (jeśli użytkownik z ConnectionString'a ma odpowiednie uprawnienia( to automatycznie utworzy się baza danych wg ostatniego pliku migration.

Napotkałem jednak problem dalej. Po odpaleniu pliku nazwaprojektu.dll z folderu publish po wpisaniu zapytania GET i nazwy tabeli, otrzymuję kod 200 i "[]", co zrozumiałe, gdyż tabela jest pusta. Natomiast gdy chcę dodać wiersz (Post) to otrzymuje błąd 400 Bad Request.

Również dodawanie rekordów z poziomu konsoli Ubuntu nie działa. Jak widać na obrazku, baza zawiera tabelę, ale (chyba z powodu rozróżniania wielkości liter) uważa, że takowa nie istnieje :(
screenshot-20180409134707.png

0

Wielkie dzięki, faktycznie, dodawanie danych do bazy jest teraz możliwe. A web API na Ubuntu zwraca dane w odpowiedzi na GET :)

Jednak POST i PUT nie działają, zwracają:

screenshot-20180410085327.png

Mimo, że dokładnie ten sam program uruchomiony pod Windowsem obsługuje wszystkie zapytania REST ( w odpowiedzi na POST odpowiada 201: Created).

Pozdrawiam,

PS:
Pewną wskazówkę znalzałem na stronie https://stackoverflow.com/questions/48708077/dotnet-core-app-doesnt-accept-post-on-linux. Może to być związane z tym, ze nginx blokuje mi POST i PUT. Problem wtedy sprowadzałby się do poprawnej konfiguracji nginx'a

0

A podłączałeś się debugiem do swojej aplikacji żeby postawić breakpoint na akcji z POST? W ten sposób będzie można wyznaczyć, czy problem leży po stronie nginx czy twojej aplikacji.

Pokaż też konfigurację nginx.

0

Konfiguracja nginx'a w pliku nginx/sites-enabled:

screenshot-20180411073439.png

Źródła do konfiguracji:

A teraz o debuggowaniu:

  • podłączyłem się do procesu odpalonego na maszynie i komendy GET i DELETE działają i łapią punkty przerwania, POST i PUT w ogóle nie łapią punktów przerwaniatylko od razu walą kodem 400 bad request,
  • z Poziomu Windowsa ten sam kod JSON zostaje przyjęty i otrzymuje komunikat 201:

screenshot-20180411090528.png

Dodatkowo aby wyeliminować kwestie uprawnień użytkownika wszedłem do bazy danych nie jako postgres tylko użytkownik z ConnectionString'a (któremu nadałem uprawnienia createdb oraz superuser) i dodawanie rekordów do bazy działa,

PS:
To wygląda tak jakby nie działały te zapytania w których występuje FromBody.

0

Postawiłem całą aplikację na innej maszynie i działa zapytanie POST, zwraca kod 201 :)

Z kolei jest inny problem z usługą kestrel service.

Aplikację wraz z kontekstem bazy danych zrobiłem w VS, potem przerzuciłem pliki na maszynę pod Ubuntu tam zrobiłem, restore, potem ef migrations, database update i dotnet publish, po odpaleniu dll z katalogu publish wszystko ładnie działa. Natomiast gdy odwołuje się to tej samej dllki z poziomu konfiguracji pliku kestrel service, wyskakuje błąd 500. (tzn w wierszu ExecStart znajduje się /usr/bin/dotnet /var/Pełna ścieżka pliku/netcoreapp2.0/publish/Nazwaaplikacji.dll)

Wyczaiłem, że gdy odpalam dllkę z pliku debug/netcoreapp2.0 (czyli "piętro" wyżej) to pojawia się taki komunikat:

screenshot-20180412120556.png

po wpisaniu samego adresu maszyny w konsoli nie pojawiają się żadne błędy, ale po wywołaniu z kontrolera metody GET pojawia się:

screenshot-20180412120827.png

Wygląda na to, że problem jest z Connection stringiem, lecz ten jest wpisany w appsettings.json, a sama aplikacja przecież działa (tylko, że z poziomu katalogu publish). Ktoś się już z tym spotkał, albo wie jak to naprawić?

PS:

A gdy próbuję postawić aplikację w kestrel-service to po żądaniu statusu wyskakuje komunikat:

screenshot-20180413105323.png

1

Taki strzał, bo nie testowałem - sprawdź, czy nie szuka appsettings.json w katalogu roboczym (working directory, tj. katalogu z którego odpalasz), a nie "obok siebie". W systemd jest opcja WorkingDirectory=/var/www/netcoreapp2.0/publish w pliku .service i wtedy ustawi odpowiednio katalog roboczy.

Ja nie mam tego problemu osobiście, bo connection stringi mam zawarte w zmiennych środowiskowych, a nie w appsettings.json ;-)

0

Cześć,

Faktycznie działa! Rozwiązanie dość proste i może dlatego po analizie komunikatów widziałem problem gdzie indziej (czyli w repozytoriach kluczy, albo ustawieniach dotyczących logowania). Rozumiem, że trzeba zawsze odwoływać się do katalogu publish (czy to Debug, czy to Release), gdzie sobie Linux tworzy wszystkie potrzebne pliki do poprawnego działania :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1