Asp.Net Core MVC na Ubuntu 16.04

Korzystając z możliwości jaka nadarzyła mi się dostając od mojego bardzo dobrego kolegi kupon w wysokości 200 zł, na wykorzystanie na stronie e24cloud.com na dowolną technologię chmurową, postanowiłem skorzystać z okazji i postawić sobie wirtualną maszynę na Linuxie Ubuntu 16.04, a co za tym idzie przetestowanie osobiście jak działa .Net Core.

Zamierzam przedstawić krok po kroku jakie czynności musiałem wykonać aby móc 'odpalić' naszą aplikację webową napisaną w .Necie na maszynie z systemem Ubuntu. Pokażę też tutaj jak ustawić nasz serwer www w tym przypadku będzie to Nginx, tak aby nasza aplikacja była widoczna nie tylko lokalnie ale też na zewnątrz i to w dodatku hostowana na porcie 80.


Pierwszą czynnością jaką musimy zrobić to udać się na stronę Microsoftu w celu pobrania wymaganych plików do uruchomienia aplikacji napisanych w .Necie, na innej maszynie niż Windows  https://www.microsoft.com/net/core#linuxubuntu 


Dla wersji Ubuntu 16.04 wydajemy kolejno polecenia widocznie poniżej.

  1. sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
  2. sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 417A0893
  3. sudo apt-get update

    1. sudo apt-get install dotnet-dev-1.0.4

    To już wystarczy aby móc pisać aplikacje w języku C# na Ubuntu, jednak my chcemy również hostować naszą aplikację w tym celu udajemy się na kolejną przydatną stronę Microsoftu, https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction  i instalujemy potrzebne nam pakiety i konfigurujemy je.

    Pozwolę sobie tutaj wypisać również krok po kroczu czynności jakie musimy wykonać:

    Instalujemy nasz serwer www.



    1. sudo apt-get install nginx
    ind
    Uruchamiamy serwer www

    1. sudo service nginx start

    Modyfikujemy plik konfiguracyjny Nginx'a

    1. sudo vim /etc/nginx/sites-available/default

    Zastępujemy całą zawartość pliku konfiguracją poniżej

    1. server { listen 80; location / { proxy_pass http://localhost:5000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }



    1. sudo service nginx restart

    Po tych czynnościach czas na przetestowanie naszej aplikacji, w tym celu stworzyłem 'szablonową' aplikacje webowa w Visual Studio 2017 i wrzuciłem ją na GitHuba https://github.com/kandascan/netcore , pobieramy do katalogu domowego repozytorium przy użyciu polecenia:

    1. git clone https://github.com/kandascan/netcore

    Po pobraniu źródeł wchodzimy do katalogu z projektem w tym przypadku:

    1. cd netcore/demo/demo

    Po czym wydajemy dwa polecenia, restore do pobrania niezbędnych pakietów i zależności dla naszej aplikacj, a drugi do uruchomienia naszej aplikacji.

    1. dotnet restore
    2. dotnet run

    Jeśli wszystko zrobiliśmy dobrze powinniśmy zobaczyć, że nasza aplikacją uruchomiła się na localhost i nasłuchuje na porcie 5000.

    1. e24@ip-178-216-200-47:~/netcore/demo/demo$ dotnet run
      Hosting environment: Production
      Content root path: /home/e24/netcore/demo/demo
      Now listening on: http://localhost:5000
      Application started. Press Ctrl+C to shut down.

    Dodatkowo możemy zauważyć że aplikacja działa także na porcie 80, dzięki zastosowaniu proxy na serwer www Nginx, nie musimy już podawać portu w przeglądarce a nasza strona będzie także dostępna na zewnątrz, gdyż po instalacji Nginx'a została automatycznie stworzona reguła w firewallu.

    1. e24@ip-178-216-200-47:~/netcore/demo/demo$ sudo ufw status verbose
      Status: active
      Logging: on (low)
      Default: deny (incoming), allow (outgoing), disabled (routed)
      New profiles: skip

      To                         Action      From
      --                         ------      ----
      22                         ALLOW IN    Anywhere
      80,443/tcp (Apache Full)   ALLOW IN    Anywhere
      22 (v6)                    ALLOW IN    Anywhere (v6)
      80,443/tcp (Apache Full (v6)) ALLOW IN    Anywhere (v6)

    Ostatnim krokiem jaki możemy wykonać to utworzenie procesu działającego w tle dla naszej aplikacji, jednak zanim jeszcze to zrobimy musimy zatrzymać naszą aplikację i wywołać w jej katalogu polecenie:

    1. dotnet publish

    Po wykonaniu tego polecenia otrzymamy ścieżkę z plikiem o nazwie naszej aplikacji z rozszerzeniem *.dll, jest to plik niezbędny aby móc uruchomić demona dotnet w tle. 

    Podążając za dokumentacją na stronie Microsoftu tworzymy servis:

    1. sudo nano /etc/systemd/system/kestrel-hellomvc.service

    Oczywiście nazwę możemy zmienić na bardziej odpowiednią dla naszej aplikacji, a nowo utworzony plik wypełniamy jak poniżej:

    1. [Unit]
      Description=Example .NET Web API Application running on Ubuntu

      [Service]
      WorkingDirectory=/home/e24/netcore/demo/demo
      ExecStart=/usr/bin/dotnet /home/e24/netcore/demo/demo/bin/Debug/netcoreapp1.1/demo.dll
      Restart=always
      RestartSec=10  # Restart service after 10 seconds if dotnet service crashes
      SyslogIdentifier=dotnet-example
      User=e24
      Environment=ASPNETCORE_ENVIRONMENT=Production

      [Install]
      WantedBy=multi-user.target

    Należy tutaj zwrócić uwagę na odpowiednie podanie ścieżki do pliku o rozszerzeniu *.dll, po publikacji naszej aplikacji oraz na nazwę użytkownika, zaleca się też utworzenie nowego użytkownika do tego celu przy użyciu polecenia adduser, oraz publikację aplikacji w katalogu /var/www/.

    Ostatnim krokiem jaki został to uruchomienie naszego servisu i sprawdzenie jego statusu:

    1. sudo systemctl start kestrel-hellomvc.service
    2. sudo systemctl status kestrel-hellomvc.service

    W wyniku czego powinniśmy dostać informacje o działaniu naszej aplikacji

    1. e24@ip-178-216-200-47:~/netcore/demo/demo$ sudo systemctl status kestrel-hellomvc.service
      ● kestrel-hellomvc.service - Example .NET Web API Application running on Ubuntu
         Loaded: loaded (/etc/systemd/system/kestrel-hellomvc.service; enabled; vendor preset: enabled)
         Active: active (running) since Wed 2017-05-10 19:11:07 UTC; 53min ago
       Main PID: 4529 (dotnet)
          Tasks: 15
         Memory: 70.8M
            CPU: 4.044s
         CGroup: /system.slice/kestrel-hellomvc.service
                 └─4529 /usr/bin/dotnet /home/e24/netcore/demo/demo/bin/Debug/netcoreapp1.1/demo.dll

      May 10 19:11:07 ip-178-216-200-47 systemd[1]: Started Example .NET Web API Application running on Ubuntu.
      May 10 19:11:07 ip-178-216-200-47 dotnet-example[4529]: Hosting environment: Production
      May 10 19:11:07 ip-178-216-200-47 dotnet-example[4529]: Content root path: /home/e24/netcore/demo/demo
      May 10 19:11:07 ip-178-216-200-47 dotnet-example[4529]: Now listening on: http://localhost:5000
      May 10 19:11:07 ip-178-216-200-47 dotnet-example[4529]: Application started. Press Ctrl+C to shut down.

    To by było na tyle, sami widzicie jak w paru krokach można wstępnie skonfigurować nasz serwer, dla aplikacji napisanych w technologi .Net Core. 
    Mam nadzieję, że ten tutorial przyda się każdemu kto będzie chciał wypróbować działanie swojej aplikacji na innym systemie niż Windows :)

Komentarze

  1. Świetny wpis.
    Podobają mi się możliwość restartowania aplikacji w przypadku awarii. Taką możliwość daje rozwiązanie, które opisałeś. Chciałbym podzielić się przykładem, który pomógł mi wykonać podobną konfigurację na serwerze Apache zamiast Nginx. Warto dodać, że możemy kilka aplikacji ASP.NET Core hostować na jednej wirtualce z linuxem z czego każda aplikaca będzie działac na porcie 80. Zrobimy to używając u rejestratora rekordów DNS typu A, możemy przekierować kilka domen na jedną maszynę wirtualną, a następnie konfigurujemy resztę na maszynie wirtualnej w sposób opisany na stronie:
    Oto link: https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-ubuntu-14-04-lts.

    OdpowiedzUsuń
  2. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  3. Jakoś nie mam przekonania do pracy na serwerach postawionych w chmurze. Oczywiście wiem, że to wszystko działa i jest bardzo wydajne. Mimo wszystko wolę maszynę namacalna, i wiem co się z nią dzieje. Firmy jak https://craftware.pl również pracują na pewno na serwerach własnych, gdyż przecież podczas pisania oprogramowania muszą stosować systemy kontroli wersji, aby sprawdzać czy wszystko z oprogramowaniem jest w najlepszym porządku.

    OdpowiedzUsuń
  4. "Słyszałem o firmie zajmującej się aseiamicrofanance (Loan Service) w styczniu 2018 r., Kiedy byłem w potrzebie finansowej, aby rozwinąć działalność restauracyjną, a dzięki szybkiej obsłudze finansowej dostałem pożyczkę i przeniosłem się do większej lokalizacji. średnio 40 USD dziennie, jako zysk z mojej restauracji i znajduję łatwość wspierania mojej rodziny, możesz się z nimi skontaktować (aseiamicrofanance@gmail.com). "

    OdpowiedzUsuń

Prześlij komentarz

Popularne posty z tego bloga

Szyfrowanie #2 - Porównanie funkcji skrótu

MongoDB w chmurze - RESTful API #2