Dla NeuroSYS zrealizowaliśmy projekt migracji środowiska deweloperskiego, bazującego na mikroserwisach, do chmury AWS, w oparciu o platformę Kubernetes. Ponieważ Klient nie miał wcześniej zasobów związanych z działaniem aplikacji w AWS oraz kontenerami, zakres naszej współpracy obejmował również szkolenia, mające na celu wdrożenie pracowników NeuroSYS, a cały projekt oparty był o inżynierię oprogramowania CI/CD.
NeuroSYS to software house, który zajmuje się na tworzeniem dedykowanych rozwiązań IT, w szczególności w obszarze aplikacji internetowych, mobilnych oraz sztucznej inteligencji. Jednym z produktów firmy jest nsFlow - zintegrowana platforma, która umożliwia projektowanie i uruchamianie aplikacji AR w celu optymalizacji procesów biznesowych.
Naszą współpracę z firmą NeuroSYS rozpoczęliśmy od przeprowadzenia wywiadu, w ramach którego ustaliliśmy dokładne oczekiwania biznesowe i technologiczne Klienta. Najważniejsze z nich to możliwość elastycznego i dynamicznego dopasowywania rozmiarów infrastruktury w zależności od potrzeb, możliwość błyskawicznego wdrażania wielu środowisk oraz infrastruktura stworzona zgodne z metodologią DevOps i podejściem IaC, które zminimalizują wysiłek związany z odtwarzaniem i kopiowaniem środowiska (dev/test/stage oraz disaster recovery). Ponadto ważnym aspektem dla Klienta było zoptymalizowanie kosztów i utrzymanie dobrych praktyk związanych z zasadami bezpieczeństwa systemów chmurowych.
Platforma chmurowa i konta AWS
Całość infrastruktury zdefiniowaliśmy i zrealizowaliśmy przy pomocy narzędzia Terraform. Kod realizacji platformy utrzymywany jest w ramach serwerów Klienta. Po stronie Klienta pozostało również przygotowanie dedykowanego repozytorium na platformie GitLab oraz przekazanie Hostersom uprawnień do użytkowania i modyfikacji kodu podczas wykonywania prac. Pełen projekt infrastruktury chmurowej został przedstawiony na poniższym rysunku.
Konto AWS zostało przygotowane przez Klienta. Wspólnie określiliśmy użycie odpowiednich ról i łańcuchów zaufania do odpowiednich kont organizacji. Komponentami, których konfiguracja pozostała po stronie Hostersów, były konta serwisowe wykorzystywane przez automatykę, wdrożenie zachowywania informacji o dostępnie i wykorzystaniu AWS API (CloudTrail) oraz elementy wykorzystywane przez IaC (bucket AWS S3, tabela Dynamo DB) w celu zachowania i ochrony infrastruktury.
Wirtualna sieć VPC
Ze względu na pełną separację środowiska produkcyjnego, utworzyliśmy niezależne od siebie sieci VPC przeznaczone dla komponentów aplikacji i usług, które wykorzystują. Wirtualne sieci rozszerzone są o obszar prywatny (podsieci prywatne), co oznacza, że nie mają one bezpośredniego dostępu do internetu. Ruch, który z nich wychodzi, przechodzi przez bramy NAT (NAT Gateways). Każdy z obszarów (prywatny i publiczny) zawiera trzy podsieci, z których każda znajduje się w innym Data Center (AZ).
Dodatkowo, w celu utworzenia szyfrowanego dostęp do obszaru prywatnego chmury z obszaru corporate office (i tylko z tego obszaru), uruchomiliśmy w obszarze prywatnym tunel VPN site-to-site.
Inne rozwiązania, które wdrożyliśmy w tym obszarze, to dedykowane połączenie obszaru prywatnego do magazynu danych S3, dzięki czemu ruch przebiega wyznaczoną siecią z wyłączeniem internetu, oraz rozłączna adresacja IP każdej sieci VPC, celem ułatwienia realizacji połączeń VPN.
Platforma Kubernetes
Klaster Kubernetes przygotowaliśmy przy pomocy Amazon Elastic Kubernetes Service, który, poza zaletami charakterystycznymi dla platformy Kubernetes, dzięki autoskalingowi umożliwia Klientowi optymalizację kosztów utrzymania klastra, obsługę wielu środowisk składających się ze zdokeryzowanych mikroserwisów, samo-naprawianie wdrożonych aplikacji i SLA z poparciem finansowym w przypadku działania usługi na poziomie poniżej 99,95%. Co bardzo ważne dla Klienta, Amazon EKS wspiera szybkie i częste deploymenty nowych aplikacji.
Dodatkowo, w celu zapewnienia funkcjonowania klastra w oczekiwany przez NeuroSYS sposób, doinstalowaliśmy do klastra następujące komponenty:
Ingress-controller trafik dla zapewnienia obsługi ingressów wraz z optymalizacją kosztów w postaci pojedynczego load balancera NLB dla wszystkich obsługiwanych ingressów.
dla zapewnienia obsługi ingressów wraz z optymalizacją kosztów w postaci pojedynczego load balancera NLB dla wszystkich obsługiwanych ingressów. Kontroler certyfikatów cert-manager odpowiedzialny za realizację dynamicznych certyfikatów SSL, komponent ma za zadanie przejąć rolę Rancherowego lets-encrypt.
odpowiedzialny za realizację dynamicznych certyfikatów SSL, komponent ma za zadanie przejąć rolę Rancherowego lets-encrypt. Autoskaler cluster-autoscaler - umożliwia automatyczne skalowanie grup maszyn wraz z reschedulingiem podów
umożliwia automatyczne skalowanie grup maszyn wraz z reschedulingiem podów Aktualizator wpisów DNS external-dns - automatyzuje obsługę adresów hostów zdefiniowanych w ingressach.
- automatyzuje obsługę adresów hostów zdefiniowanych w ingressach. Narzędzie backup-restore Velero tworzy kopie zapasowe wszystkich elementów klastra oraz ich danych
tworzy kopie zapasowe wszystkich elementów klastra oraz ich danych Service mesh Linkerd - realizuje automatyczne mTLS, metryki ruchu oraz sukcesu requestów poszczególnych usług
Wszystkie powyższe narzędzia wdrożyliśmy przy użyciu i pod kontrolą narzędzia Helm, które pozwala Klientowi na utrzymywanie odpowiednich wartości konfiguracji poszczególnych narzędzi dla danego klastra w kodzie zgodnie z metodologią DevOps, kontrolę zmian i ewentualnych powrotów (roll-back) do poprzednich konfiguracji oraz łatwe utrzymanie i aktualizację pełnej konfiguracji danego narzędzia.
Bazy danych
Tworząc bazę danych braliśmy przede wszystkim pod uwagę wymagania Klienta związane ze zgodnością z obecnie przyjętymi praktykami w zakresie funkcjonowania i utrzymania oprogramowania. Dlatego też uruchomiliśmy bazy postgresowe w formie kubernetesowych podów, wykorzystujących dyski EBS poprzez PersistentVolumeClaim. Jest to forma zgodna ze wzorcem architektury mikroserwisowej, w której poszczególne mikroserwisy posiadają własną bazę danych, a zespół odpowiedzialny za mikroserwis, odpowiada również za jej utrzymanie i konfigurację. Zastosowanie takiej bazy danych pozwoliło nam również na separację na poziomie używania zasobów sprzętowych odpowiednich baz danych, należących do odpowiadających im mikroserwisów.
Szyny danych RabbitMQ
Podobnie jak w przypadku baz danych, wzięliśmy pod uwagę wymagania związane ze zgodnością z obecnymi praktykami w funkcjonowaniu i utrzymaniu oprogramowania i uruchomiliśmy RabbitMQ w formie kubernetesowych podów, wykorzystujących dyski EBS poprzez PersistentVolumeClaim. Jest to forma zgodna ze wzorcem architektury mikroserwisowej, w której dana grupa mikroserwisów posiada własną szynę danych, a dany zespół jest również odpowiedzialny za jej utrzymanie i konfigurację. Zaletą tego rozwiązania jest separacja na poziomie używania zasobów sprzętowych odpowiednich szyn danych należących do odpowiadających im grup mikroserwisów. Co ważne, koszt szyny danych w tym przypadku jest składową kosztu klastra Kubernetesa, z kolei ochrona danych dyskowych realizowana jest przez open sourcowe narzędzie Velero.
Przed migracją powyższego rozwiązania przeprowadziliśmy stress i load testy, żeby upewnić się, że zastosowane narzędzia są gotowe do planowanej migracji.
Monitoring klastrów EKS
Do monitoringu klastrów EKS oraz reszty usług AWS skonfigurowaliśmy narzędzie DataDog, które umożliwia stworzenie pojedynczego pulpitu monitorowania (single pane of glass), znacząco skracając czas reakcji na awarie i analizę incydentów. Wdrożyliśmy również DataDog agent w klastrze Kubernetes, dzięki któremu Klient może samodzielnie ocenić przydatność, funkcjonalności oraz koszty związane z używaniem DataDog.
Wdrożenie aplikacji WEB
Instalację stosu aplikacji na platformie Kubernetes wykonaliśmy przy pomocy menadżera pakietów Helm, który obecnie jest najczęściej używanym menadżerem do zarządzania aplikacjami w środowisku Kubernetes. Funkcjonalności Helm pozwalają wykorzystywać go w sposób zautomatyzowany (pipelines), umożliwiają też umieszczanie nowych wersji aplikacji, wracanie do poprzednich wersji czy usuwanie ich w ustandaryzowany sposób, korzystając z definicji aplikacji lub całego ich zestawu w formie tzw. chartów, czyli definicji wszystkich komponentów niezbędnych w klastrze do działania aplikacji.
Pozostałe rozwiązania
W charakterze magazynu obiektów (pliki statyczne, kopie, archiwalne logi, pliki stanu infrastruktury) zastosowaliśmy AWS S3. W celu szyfrowania danych w usługach AWS (dyski EBS, magazyn S3, bazy danych itp.) w integracji z natywnymi metodami uwierzytelnienia i autoryzacji, wykorzystaliśmy AWS KMS (Key Management Service). Dla przechowywania dynamicznych parametrów dostępnych dla aplikacji przy użyciu natywnych dla AWS serwisów IAM oraz KMS, w tym szyfrowanych sekretów, parametrów inicjalizacyjnych itp., zastosowaliśmy usługę Systems Manager Parameter Store, natomiast do przechowywania sekretów, ze względu na funkcjonalność automatycznej rotacji sekretów, wdrożyliśmy Secret Managera.
Podsumowanie
Dla Firmy NeuroSYS zrealizowaliśmy migrację platformy nsFlow do środowiska AWS, opartego na klastrach Kubernetes. Całe środowisko zostało stworzone w zgodzie z podejściem IaC. Ze względu na to, że po przeprowadzeniu migracji, Klient zaplanował zbudowanie zespołu zajmującego się całodobowym suportem migrowanej aplikacji, cały proces przeprowadziliśmy zgodnie z filozofią CI/CD, dzięki czemu pracownicy Klienta mogli na bieżąco wdrażać się w realizowany projekt. Ponadto, wszystkie zaimplementowane elementy kodu, uzupełniliśmy o informacje „read me”, zawierające podstawowe informacje dotyczące każdego zastosowanego rozwiązania. Dzięki temu proces wdrożenia zespołu Klienta przebiegł szybko i sprawnie.
PYTANIA? SKONTAKTUJ SIĘ Z NAMI
Zobacz również:
Migracja do Amazon Web Services aplikacji i serwisów DANONE
Wdrożenie i opieka nad infrastrukturą chmurową w AWS dla Displate
Migracja bazy danych MySQL do Amazon Aurora platformy
Nowa infrastruktura w AWS dla Omnipack z użyciem IaC
Migracja serwisu edukacyjnego EduNect do chmury AWS
System ERP (z ang. Enterprise Resources Planning) to oprogramowanie do kompleksowego zarządzania przedsiębiorstwem. Kryjące się w skrócie ERP „planowanie zasobów” obejmuje kontrolę i zarządzanie najważniejszymi zasobami i procesami w niemal każdym obszarze biznesowym firmy: sprzedaż, finanse, księgowość, magazyn, kadry, zaopatrzenie, produkcja itd.
Jego najważniejszym wyróżnikiem jest praca na jednej bazie danych. To oznacza, że dane wprowadzone w jednym obszarze systemu, np. w handlu, są natychmiast widoczne przez innych użytkowników, np. u zarządzajacego produkcją oraz w dziale księgowym czy na magazynie.
Przeczytaj poniższy artykuł z najczęstszymi pytaniami (FAQ) o system ERP w 2021 r.
Różne oblicza inżynierii odwrotnej
W dobie coraz częściej wykorzystywanego wytwarzania metodą rapid prototyping/rapid forming, na większą uwagę zasługuje wykorzystywanie metody odtwarzania fizycznych części w środowisku CAD, czyli tzw. projektowanie odwrotne (reverse engineering). Zapewne przyczynia się do tego rosnąca konkurencja w branży skanerów 3D, jak i samych urządzeń drukujących z coraz większego wachlarza materiałów.
Bernard Pacula
Możliwości systemów CAD w zakresie pracy na zaimportowanej chmurze punktów są bardzo różne i metody pracy, na jakie pozwalają, również mogą od siebie odbiegać. Ważną również kwestią jest postać danych wejściowych. Jeśli w posiadaniu mamy urządzenie skanujące, zintegrowane dedykowanym interfejsem z narzędziem CAD, możliwe jest tworzenie szkiców lub nawet powierzchni, bezpośrednio po analizie odpowiednich ścianek modelu. Najczęściej jednak konstruktor dostaje dane wejściowe i na ich podstawie ma wykonać bryłę bądź powierzchnię 3D.
Najprostszą wersją inżynierii odwrotnej jest odtworzenie geometrii na podstawie zdjęć konstrukcji. Brzmi to może dość nietypowo, ale dawniej nie było takiej dostępności skanerów, lub też nie zawsze geometria mogła zostać poddana skanowaniu. W takiej sytuacji można wykonać dość prymitywną metodą odtworzenie kształtu. Wystarczy mieć zdjęcia obiektu w kilku rzutach, umożliwiające odtworzenie całej konstrukcji. Zacząć należy od umieszczenia obrazu w odpowiednim rzucie, jako fragmentu szkicu (Rys. 1).
Rys. 1
Oczywiście, wstawienie takiego obrazu bez dodatkowych ustawień jest zazwyczaj niedostosowane do proporcji i rzeczywistych wymiarów. Aby możliwe było wykorzystanie takich zdjęć, konieczne jest dokonanie co najmniej kilku pomiarów w celu dostosowania skali umieszczanego obrazu.
cały artykuł dostępny jest w wydaniu 1/2 (88/89) styczeń-luty 2015
Leave a Comment