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

Odpowiedz Nowy wątek
2018-03-12 15:31
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,

Pozostało 580 znaków

2018-04-09 13:49
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

Spróbuj SELECT * FROM "Clients" - w pgSQL jak coś jest w cudzysłowach to wielkość znaków jest respektowana, a jak bez nich - ignorowana. - Ktos 2018-04-09 18:22

Pozostało 580 znaków

2018-04-10 08:57
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/que[...]p-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

edytowany 2x, ostatnio: GreatGreG, 2018-04-10 12:20

Pozostało 580 znaków

2018-04-10 19:39
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.

Pozostało 580 znaków

2018-04-11 09:11
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.

edytowany 2x, ostatnio: GreatGreG, 2018-04-11 09:19

Pozostało 580 znaków

2018-04-12 12:16
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

edytowany 1x, ostatnio: GreatGreG, 2018-04-13 10:54

Pozostało 580 znaków

2018-04-13 19:48
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 ;-)

Pozostało 580 znaków

2018-04-16 08:26
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 :)

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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