Menu

Skontaktuj się
Logo
Prasa

Kubernetes i platformy kontenerowe z OTOKO®

Kubernetes nie może oznaczać działania na ślepo.

Kontenery ułatwiają pakowanie aplikacji. Do zastosowania produkcyjnego często brakuje jednak jeszcze reguł dostępu, procedury wydawania, aktualizacji i przywracania danych. OTOKO® buduje z tego platformę Kubernetes dopasowaną do Państwa aplikacji i dostępnych kompetencji eksploatacyjnych oraz testuje jej wykorzystanie wspólnie z Państwa zespołem deweloperskim.

Czym się dla Państwa zajmujemy
Przednie panele serwerów jako symbol mocy obliczeniowej, zdjęcie ilustracyjne
Kubernetes i platformy kontenerowe

Planowanie, realizacja i uzgodniona eksploatacja przez OTOKO®

Zdjęcie ilustracyjne · nie jest to zdjęcie lokalizacji dostawcy

Państwa zlecenie dla OTOKO®

Od pojedynczych kontenerów do platformy gotowej do eksploatacji.

Jeden zespół już z powodzeniem wdraża zmiany, inny korzysta z własnych skryptów, a zmiany produkcyjne wciąż wymagają indywidualnych uzgodnień. Przed rozbudową platformy potrzebne są wspólne procesy. Jeśli decyzja o Kubernetes jeszcze nie zapadła, najpierw sprawdzamy, czy jego korzyści uzasadniają dodatkowy nakład eksploatacyjny w Państwa przedsięwzięciu.

Co mogą Państwo nam zlecić

Do budowy platformy należą uzgodnione dostępy, procedura wdrażania i procesy eksploatacyjne. Aplikacja pilotażowa służy do przetestowania ścieżki aż do wydania. Dokumentacja i instruktaż przygotowują przekazanie, a bieżąca obsługa i aktualizacje są uzgadniane jako odrębny zakres usług.

Szczegóły usług

Zakres usługi

Opieka nad platformą od pierwszego klastra do wydania.

Wybór platformy, dostępy zespołów i wdrażanie są analizowane wspólnie. Aplikacja pilotażowa umożliwia sprawdzenie procesów, a aktualizacje i dane trwałe są uwzględniane w planowaniu eksploatacji już podczas budowy platformy.

Wybór odpowiedniej platformy

Wybór platformy zaczyna się od aplikacji i zdolności eksploatacyjnych. Odpowiednie warianty są następnie oceniane pod względem tego, jakie zadania przejmuje dostawca, a jakie pozostają w Państwa zespole. Ten podział wpływa na decyzję w takim samym stopniu jak wymagania techniczne.

Na tej podstawie Państwa zespół pracuje dalej

Uzasadniony docelowy model platformy z rozdzielonymi zakresami odpowiedzialności.

Realizacja techniczna

Architektura klastra i wybór platformy

Zarządzana płaszczyzna sterowania i samodzielnie utrzymywany klaster wiążą się z różnymi zadaniami. Planujemy węzły robocze, sieci i wymagania dotyczące dostępności oraz sprawdzamy, czy Kubernetes w ogóle pasuje do danego obciążenia. Przy decyzji liczą się także zasoby eksploatacyjne i nakład na aktualizacje.

Dołączanie zespołów według jasnych reguł

Zespoły potrzebują zdefiniowanych obszarów pracy, zasobów i reguł komunikacji. Te podstawy konfigurujemy i wyjaśniamy przewidziane zatwierdzenia. Dzięki temu widać, co zespoły deweloperskie mogą wdrażać samodzielnie, a gdzie niezbędne jest uzgodnienie z eksploatacją.

Na tej podstawie Państwa zespół pracuje dalej

Gotowa do użycia struktura dzierżawców i dostępu dla zaangażowanych zespołów.

Realizacja techniczna

Namespaces, RBAC i reguły sieciowe

Zespoły potrzebują uregulowanych dostępów i zasobów. Namespaces, role, limity i komunikację sieciową planujemy łącznie. Dane dostępowe i konfiguracja otrzymują określone ścieżki zarządzania, aby wspólny klaster nie prowadził do niekontrolowanego wzajemnego dostępu.

Przejrzyste dostarczanie nowych wersji

Droga od zweryfikowanego obrazu kontenera do działającej wersji musi być możliwa do prześledzenia. Testy i wdrażanie są włączane w uzgodniony przebieg i sprawdzane na aplikacji pilotażowej. Zespoły deweloperskie i eksploatacyjne wspólnie weryfikują przy tym zatwierdzenia oraz zachowanie systemu podczas wdrażania.

Na tej podstawie Państwa zespół pracuje dalej

Przetestowany proces wdrażania dla aplikacji pilotażowej oraz szablony dla kolejnych zespołów.

Realizacja techniczna

CI/CD, rejestr i GitOps

Obrazy kontenerów, kontrole i konfigurację wdrożeń włączamy w przejrzystą ścieżkę wydań. Helm lub GitOps mogą być przy tym odpowiednimi narzędziami. Zatwierdzenia, ścieżki powrotu i postępowanie z wadliwymi wydaniami uzgadniamy wspólnie z zespołem aplikacyjnym.

Wsparcie w zakresie aktualizacji, danych i awarii

Aktualizacje platformy i przywracanie danych dotyczą również danych trwałych i podłączonych usług. Te zależności, wraz z monitoringiem, są uwzględniane w planowaniu eksploatacji. Powstają z tego konkretne zadania i procedury dotyczące utrzymania oraz postępowania w przypadku awarii.

Na tej podstawie Państwa zespół pracuje dalej

Plan eksploatacji z procedurami aktualizacji, ścieżkami alarmowania i testami przywracania.

Realizacja techniczna

Dane trwałe, aktualizacje i obserwowalność

Metryki, logi i alarmowanie muszą wyjaśniać zachowanie aplikacji. Planujemy aktualizacje klastra oraz kopie zapasowe i przywracanie konfiguracji i danych. Udany restart poda nie zastępuje testu przywracania danych.

Planowanie i realizacja w szczegółach

Kubernetes wymaga koncepcji eksploatacji dla platformy i aplikacji.

Działający klaster to ważny moduł, ale jeszcze nie pełna eksploatacja aplikacji. Rozwój oprogramowania, obsługa platformy i odpowiedzialność za dane muszą ze sobą współdziałać. Nasze podejście łączy konfigurację techniczną z procesami, których Państwa zespoły potrzebują do wydań, aktualizacji i obsługi awarii.

Wyważenie korzyści i nakładu związanego z eksploatacją

Przed wyborem platformy analizujemy, jakie aplikacje mają zostać na niej uruchomione i jakie potrzeby mają zespoły. Jak dzisiaj udostępniane są nowe wersje? Jakie dane muszą być zachowane na trwałe? Kto odpowiada za zmiany na platformie? Te pytania pomagają zawęzić potrzebny zakres. Kubernetes może mieć sens, ale musi być dopasowany do aplikacji i dostępnych kompetencji. Decyzja podjęta wyłącznie na podstawie pożądanej technologii nie odpowiada jeszcze na pytanie o dodatkowy nakład organizacyjny i techniczny.

Dlatego odpowiednie warianty są oceniane również pod względem podziału zadań. Przy usłudze zarządzanej trzeba wyjaśnić, jakie prace przy aplikacji, konfiguracji i danych są wciąż niezbędne. Model docelowy określa zadania pozostające po Państwa stronie i wskazuje, które z nich OTOKO® przejmuje w ramach zlecenia. Reprezentatywna aplikacja pilotażowa pozwala skonkretyzować wymagania. Na jej podstawie można sprawdzić, czy wybrana struktura i przewidziane procesy rzeczywiście spełniają oczekiwania, zanim dołączą kolejne zespoły lub aplikacje.

Włączanie zespołów deweloperskich przy użyciu sprawdzonej ścieżki wydań

Zespół potrzebuje więcej niż dostępu do klastra. Musi wiedzieć, gdzie może pracować, jak przydzielane są zasoby i jakie zatwierdzenia obowiązują dla zmiany produkcyjnej. Te podstawy są wspólnie ustanawiane i łączone ze ścieżką wdrażania. Obrazy kontenerów, kontrole i pożądana wersja muszą być ze sobą jednoznacznie i przejrzyście powiązane. Konkretne wdrożenie jest przy tym dostosowane do Państwa aplikacji i istniejących narzędzi. Już funkcjonujące procesy są włączane do modelu docelowego w zakresie, w jakim do niego pasują.

Pierwsze wydanie jest realizowane wspólnie. Sprawdzamy przy tym nie tylko udany start, lecz również zrozumiałość przebiegu: czy komunikaty o błędach można przypisać do przyczyny, czy zatwierdzenie jest jednoznaczne i czy zespoły rozwoju i eksploatacji wiedzą, kiedy muszą zareagować? Uzgodnione przypadki błędów i sposoby wycofania zmian są również omawiane lub testowane. Powstała w ten sposób dokumentacja ma wspierać kolejne wydania. Dzięki temu Państwa zespół otrzymuje użyteczny sposób pracy, a nie tylko środowisko techniczne, którego obsługę trzeba będzie dopiero później samodzielnie rozpracować.

Uwzględnienie danych trwałych, aktualizacji platformy i obsługi

Kontenery można ponownie udostępnić, jednak powiązane z nimi dane i podłączone usługi wymagają własnych procedur. Wspólnie ustalamy, jakie informacje muszą być zachowane na trwałe i jak sprawdzane jest ich odzyskiwanie. Należy do tego również kolejność, w jakiej aplikacja i dane stają się ponownie użyteczne. Procedura tworzenia kopii zapasowych musi więc być dopasowana do rzeczywistej aplikacji. Zadania są wyraźnie przypisywane, aby nie powstała nieumyślnie luka między obsługą platformy a odpowiedzialnością za aplikację.

Także aktualizacje platformy wymagają przygotowania i uzgodnienia. Zależności, możliwości testowania i wymagane zatwierdzenia są opisane w procedurze eksploatacyjnej. Monitorowanie i ścieżki zgłaszania określają, jak problemy są wykrywane i przekazywane odpowiednim osobom. Przy stałej obsłudze zakres usług wskazuje, jakie zadania platformowe i eksploatacyjne są objęte, a jakie pozostają po stronie Państwa zespołów. Takie rozgraniczenie ułatwia świadome przyjmowanie nowych wymagań w przyszłości i realistyczne planowanie niezbędnej pracy na platformie.

Jak współpracujemy

Państwo znają swoją działalność.
My wykonujemy uzgodnione prace w chmurze.

Nie muszą Państwo samodzielnie organizować każdego technicznego kroku. Dokumentujemy zadania i decyzje oraz włączamy Państwa zespół tam, gdzie potrzebna jest jego wiedza lub zatwierdzenie.

01

Zrozumienie aplikacji i potrzeb platformowych

Reprezentatywna aplikacja pokazuje wymagania dotyczące zasobów, danych i wdrażania. Zdolności eksploatacyjne i warianty platformy oceniamy wspólnie.

Państwa wkład: Proszę zebrać razem zespoły deweloperskie i eksploatacyjne oraz wybrać odpowiednią aplikację pilotażową.

02

Testowanie ścieżki wydawania

Konfigurowane są platforma, dostępy i procedura wdrażania. Za pomocą pilotażu sprawdzamy, czy zespoły mogą przeprowadzać wydania zgodnie z przewidzianym przebiegiem.

Państwa wkład: Państwa zespół deweloperski dostarcza aplikację oraz sprawdza zatwierdzenia i poprawność biznesową.

03

Przekazanie odpowiedzialności za aktualizacje i dane

Zadania eksploatacyjne, procedura aktualizacji i przywracanie danych są wyjaśniane i przypisywane. Wynika z tego również możliwy zakres bieżącej obsługi.

Państwa wkład: Proszę potwierdzić zakres odpowiedzialności za aplikację, dane trwałe i zmiany na platformie.

Sala spotkań w biurze OTOKO® w Kolonii

Przykładowy scenariusz projektu

Z pojedynczych kontenerów powstaje platforma zespołowa

Tak mogłoby wyglądać wspólne przedsięwzięcie. Konkretny zakres wynika z Państwa sytuacji wyjściowej.

  1. Sytuacja wyjściowa

    Kilka aplikacji działa w kontenerach, ale wdrożenia i eksploatacja różnią się w zależności od zespołu.

  2. Nasze podejście

    Testujemy wspólne reguły wdrażania i procesy eksploatacyjne na wybranej aplikacji.

  3. Model docelowy

    Punkt startowy wielokrotnego użytku dla kolejnych zespołów, obejmujący role, ścieżkę wydań i uzgodnioną odpowiedzialność za eksploatację.

Co Państwo otrzymują

Rezultaty, na których
Państwa zespół może dalej pracować.

  • Gotowa do eksploatacji platforma Kubernetes jako kod

  • Koncepcja bezpieczeństwa i wielodzierżawności z zasadami

  • Podręcznik eksploatacji z procedurami aktualizacji i przywracania

Od zainteresowania do konkretnego zlecenia

Jak przygotowujemy
Państwa projekt.

Do pierwszej konsultacji te dokumenty nie muszą być jeszcze kompletne. Wspólnie ustalamy, co jest już dostępne i jakie informacje ma uzupełnić ocena.

Przydatne na początek

  • Aplikacje, obrazy i istniejące procesy wdrażania
  • Dane trwałe i wymagania dotyczące dostępności
  • Role w zespole i zasoby do eksploatacji platformy

Jak powstaje konkretna oferta

Zakres usług, zaangażowanie Państwa zespołu, potrzebne dostępy, kryteria odbioru i przekazanie są ujęte w ofercie. Opłaty dostawcy, usługi projektowe i bieżąca eksploatacja są rozdzielone w przejrzysty sposób.

Omówmy ocenę

Przed rozpoczęciem

Państwa pytania.
Jasne odpowiedzi.

Co otrzymujemy w ramach usługi Kubernetes i platformy kontenerowe?

Gotowa do eksploatacji platforma Kubernetes jako kod. Koncepcja bezpieczeństwa i wielodzierżawności z zasadami. Podręcznik eksploatacji z procedurami aktualizacji i przywracania. Zakres i kryteria odbioru uzgadniamy na początku.

Czy możemy zacząć od istniejącego środowiska?

Tak. Analizujemy Państwa istniejące aplikacje, interfejsy i procesy eksploatacyjne oraz wspólnie określamy niezbędne zmiany. Całkowita przebudowa nie jest automatycznie konieczna.

Jak określa się nakład pracy i odpowiedzialność?

Po inwentaryzacji uzgadniamy pakiety prac, zakresy odpowiedzialności, kryteria odbioru i przekazanie. Na tej podstawie powstaje oferta dla konkretnego zakresu projektu.

Co obejmuje zarządzana usługa Kubernetes?

Zależy to od dostawcy i taryfy. Aplikacja, konfiguracja, uprawnienia i dane nie są automatycznie objęte pełną opieką. Te zadania rozgraniczamy w modelu platformy i eksploatacji.

Czy OTOKO® może przejąć tylko budowę platformy?

Tak. Budowę, wspólną opiekę i bieżącą eksploatację można uzgodnić osobno. Udokumentowane przekazanie stanowi podstawę dla Państwa wewnętrznego zespołu.

Kubernetes i platformy kontenerowe z OTOKO®

Czego Państwa zespół deweloperski potrzebuje od platformy?

Reprezentatywna aplikacja pokazuje często więcej niż długa lista narzędzi. Na jej przykładzie omawiamy wdrażanie, przechowywanie danych i eksploatację oraz określamy, co musi zapewniać Państwa platforma.

Umów pierwszą konsultację: Kubernetes i platformy kontenerowe

Nasi partnerzy

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Dostępność

Dostosuj wygląd strony do swoich potrzeb.

Dla tej strony nie ma jeszcze wersji w prostym języku.

Ustawienia obowiązują obecnie tylko podczas tej wizyty. Trwałe zapisywanie możesz włączyć w ustawieniach plików cookie.