Szybkie testowanie lokalnego API z ngrok

Na początku miesiąca miałem przyjemność udać się do Danii, aby wziąć udział w firmowym hackatonie. Wraz z dwoma osobami pracowałem tam nad prostym projektem, który miał niejako rozszerzyć możliwości GitHuba. Bez wchodzenia w zbędne szczegóły dotyczące samego projektu, całe flow prezentowało się następująco:

 

  1. Użytkownik tworzy Pull Request na GitHub
  2. GitHub wykonuje żądanie HTTP do webhooka naszej usługi
  3. Usługa coś robi
  4. Usługa wywołuje API GitHub

 

Pierwsze MVP wykreowało się stosunkowo szybko. Pojawiła się jednak drobna niedogodność. Otóż, projekt, który tworzyliśmy znajdował się na naszych lokalnych maszynach co oznaczało, że dostęp do API (co za tym idzie do webhooka) był możliwy z poziomu localhost:5000. Nie był to zatem adres, który mogliśmy podpiąć do GitHuba, aby zobaczyć czy całe flow działa poprawnie, ponieważ localhost (jak sama nazwa wskazuje) referuje do maszyny, na której aktualnie się znajdujemy. Podając ten link, GitHub próbowałby wywołać swoje lokalne API dostępne na porcie 5000. Rozwiązanie tego problemu było oczywiście banalne. Wystarczyło upublicznić adres usługi tak, aby był on osiągalny dla zewnętrznych podmiotów. Co więcej, posiadaliśmy całą infrastrukturę potrzebną, aby w relatywnie krótkim czasie wrzucić to na serwer jako publicznie dostępny kontener Dockera. Szybko jednak pojawiło się zasadne pytanie: po co? Czy na prawdę musimy bawić się w DevOps, aby sprawdzić czy otrzymujemy JEDNO żądanie HTTP? Czy na prawdę chcemy poświęcać czas, którego i tak mamy mało na spięcie mikro-projektu z Dockerem i CI/CD? Odpowiedź była oczywista – szukamy alternatywy. Czegoś co pozwoli na sprawne testowanie lokalnego API bez zbędnych ceregieli. Trafiliśmy na ngrok.

 

Czym jest ngrok?

ngrok wpisywał się dokładnie w to czego potrzebowaliśmy. Idea jest bardzo prosta. Podajemy port http (dla localhost), który chcemy upublicznić, następnie uruchamiamy program i bum… zwrócony zostaje nam publiczny adres HTTP oraz HTTPS, który forwarduje żądania do lokalnego API. Proste, a jakie genialne. Trzeba jednak przyznać, że nazwa tego programu jest bardzo niefortunna z uwagi na konwencję nazewniczą bibliotek Angulara, które posiadają prefiks „ng”. Osobiście jest to dla mnie dość mylące, ale… nie każdy robi frontend 😀

 

Uruchomienie ngrok na lokalnej maszynie

Zacznijmy od stworzenia prostego API w ASP.NET Core, aby móc przetestować program:

 


    [Route("api/[controller]")]
    public class TestController : Controller
    {
        [HttpGet]
        public string Get() => "Hello from hackaton!";
    }

 

Lokalnie uruchomiona usługa (na Kestrelu) będzie dostępna pod wcześniej wspomnianym adresem localhost:5000, a akcja Get pod adresem localhost:5000/api/Test.  Posiadając API możemy przejść dalej.

W celu uruchomienia ngrok na lokalnej maszynie udaj się pod adres ngrok.com/download i pobierz program odpowiednio dla Twojego systemu operacyjnego. W moim przypadku będzie to Windows. Po pobraniu ZIP-a i rozpakowaniu pliku ngrok.exe, uruchom program. Powinieneś zobaczyć następujący ekran:

 

 

Następnie wykonajmy pierwsze polecenie przedstawione w sekcji EXAMPLES (oczywiście zmodyfikowane pod nasze potrzeby):

ngrok http 5000

Tym poleceniem wskazujemy port naszego localhost, który chcemy upublicznić. W naszym przypadku jest to 5000 czyli domyślny port Kestrela. Po kliknięciu Enter wszystko powinno zostać uruchomione:

 

 

Jak widzisz ngrok wygenerował publiczny adres (8c906c76.ngrok.io), który dostępny jest za pośrednictwem HTTP jak i HTTPS. Obie wersje forwardują jednak żądania na adres localhost:5000. Zweryfikujmy działanie programu wykonując testowy request HTTP GET przy pomocy Postmana:

 

 

Same żądania zostają odpowiednio odnotowane w konsoli:

 

 

Jeżeli ta forma do Ciebie nie przemawia lub potrzebujesz więcej informacji diagnostycznych, to możesz skorzystać z webowego interfejsu dostępnego pod adresem localhost:4040:

 

 

Czy to wszystko?

Powyższe „demo” to tylko jedna z wielu opcji ngrok. Z tego co można znaleźć na stronie inne, ciekawe ficzery to :

  • obsługa WebSocket
  • tunelowanie TCP
  • wildcard dla domen
  • IP whitelisting

Część z opcji jest darmowa, część wymaga zakupu płatnej wersji programu. Mnie osobiście wystarczy opisany dziś „bajer” 😉

You may also like...