მთავარ კონტენტზე გადასვლა

Cloud და DevOps

გაშვება, რომელიც რიტუალს აღარ საჭიროებს

CI/CD, კონტეინერიზაცია, გარემოების სტანდარტიზაცია და ინფრასტრუქტურა კოდად — რომ გაშვება ჩვეულებრივი სამუშაო იყოს, არა მოვლენა.

პრობლემა

დეპლოი ერთმა ადამიანმა იცის

გაშვება ხელით კეთდება, ნაბიჯები ჩატში წერია, staging პროდაქშენს აღარ ჰგავს და rollback ნიშნავს ბექაპიდან ამოღებას. კონფიგურაცია სერვერზე ჩასწორდა და კოდში აღარ არსებობს — შემდეგი ინსტალაცია იმავე შედეგს ვეღარ იმეორებს.

  • გაშვება ერთ ადამიანზეა დამოკიდებული
  • გარემოები ერთმანეთს დაშორდა
  • rollback გეგმა არ არსებობს
  • საიდუმლოები ჩატსა და .env ფაილებშია

რას ვაწვდით

გაშვება, რომელიც რიტუალს აღარ საჭიროებს

Pipeline

build, ტესტი, image და გაშვება ერთ გამეორებად ჯაჭვად — ხელით ნაბიჯების გარეშე.

კონტეინერიზაცია

აპლიკაცია და მისი დამოკიდებულებები image-ში, ვერსიით და გამეორებადი build-ით.

გარემოების პარიტეტი

dev, staging და production ერთი აღწერიდან — განსხვავება მხოლოდ პარამეტრებში.

საიდუმლოების მართვა

წვდომა როლებით, საიდუმლოები რეპოზიტორიის გარეთ და როტაციის პროცედურით.

Rollback და გაშვების სტრატეგია

წინა ვერსიაზე დაბრუნება წუთებში, არა ბექაპიდან აღდგენით.

დაკვირვებადობა გაშვების შემდეგ

მეტრიკები, ლოგები და alert-ები, რომლებიც პრობლემას მომხმარებელზე ადრე აჩვენებს.

არქიტექტურა

არქიტექტურა

  1. 01Commitკოდი და კონფიგურაცია ერთ რეპოზიტორიაში
    • Git
    • Semantic versioning
  2. 02Buildგამეორებადი image, ვერსიით
    • Docker
    • Registry
  3. 03შემოწმებაავტომატური, ხელით ნაბიჯების გარეშე
    • GitHub Actions
    • Lint / types
    • Smoke test
  4. 04გაშვებაstaging და პროდაქშენი ერთი აღწერიდან
    • Dokploy
    • Compose
    • Terraform
  5. 05დაკვირვებამეტრიკები და ლოგები გაშვების ირგვლივ
    • Prometheus
    • Grafana
    • Loki
  6. 06Rollbackწინა ვერსია წუთებში, არა ბექაპიდან
    • Blue-green
    • Canary
    • Migrations
გაშვების ჯაჭვი — commit-იდან პროდაქშენამდე, დაბრუნების გზის შენარჩუნებით

შესაძლებლობები

შესაძლებლობები

თითოეული პუნქტი აღნიშნულია: დადასტურებული პროდაქშენ გამოცდილება თუ საინჟინრო შესაძლებლობა.

Docker და კონტეინერიზებული სერვისები

Proven

ჩვენივე პროდაქშენ სერვისები კონტეინერებში მუშაობს — მონიტორინგის, ლოგირებისა და შიდა ინსტრუმენტების სტეკის ჩათვლით.

  • Docker
  • Compose
  • Registry

CI/CD მილსადენები

Proven

build, ტესტი და გაშვება GitHub Actions-ით, Dokploy-ზე დაფუძნებული გარემოებით.

  • GitHub Actions
  • Dokploy
  • Git

მონაცემთა ბაზის მიგრაციები და ბექაპი

Proven

სქემის ვერსირება, ბექაპის როტაცია და აღდგენის რეპეტიცია scratch ბაზაში.

  • PostgreSQL
  • Migrations
  • pg_dump

Reverse proxy და TLS

Proven
  • nginx
  • Traefik
  • Let's Encrypt

ინფრასტრუქტურა კოდად

Capability
  • Terraform
  • Ansible
  • GitOps

Kubernetes

Capability
  • Kubernetes
  • Helm
  • Ingress

Blue-green და ეტაპობრივი გაშვება

Capability
  • Blue-green
  • Canary
  • Feature flags

აპლიკაციური დაკვირვებადობა

Capability

მეტრიკები და ლოგები იმავე პლატფორმაზე, რომელზეც ინფრასტრუქტურის მონიტორინგი დგას.

  • Prometheus
  • Loki
  • Grafana

პროცესი

პროცესი

  1. 01

    აუდიტი

    როგორ იშლება კოდი დღეს და სად წყდება ჯაჭვი.

  2. 02

    სტანდარტი

    შეთანხმებული build, ვერსირება და გარემოების აღწერა.

  3. 03

    Pipeline

    ავტომატიზაცია ერთი სერვისისთვის, ბოლომდე.

  4. 04

    გავრცელება

    იგივე შაბლონი დანარჩენ სერვისებზე.

  5. 05

    დაკვირვება

    მეტრიკები, ლოგები და alert-ები გაშვების ირგვლივ.

  6. 06

    გადაცემა

    დოკუმენტაცია და გუნდის ტრენინგი.

ტექნოლოგიური სტეკი

ტექნოლოგიური სტეკი

კონტეინერები
DockerComposeRegistryKubernetes
CI/CD
GitHub ActionsDokployGitSemantic versioning
ინფრასტრუქტურა კოდად
TerraformAnsiblecloud-init
Runtime
nginxTraefikPostgreSQLRedis
დაკვირვებადობა
PrometheusGrafanaLokiAlertmanager

თანამშრომლობის მოდელი

თანამშრომლობის მოდელი

პროექტი

ერთჯერადი scope: აუდიტი, მიგრაცია ან დანერგვა ფიქსირებული შედეგით.

რეტეინერი

ყოველთვიური საინჟინრო საათები — სპეციალისტზე წვდომა მოთხოვნისამებრ.

Co-Managed

NetWizard და თქვენი შიდა გუნდი ერთად, გაყოფილი პასუხისმგებლობით.

გამოყენების შემთხვევები

გამოყენების შემთხვევები

გაშვება ღამის სამუშაოა

ყოველი გამოშვება ხელით ნაბიჯების სიაა. ვაწყობთ pipeline-ს, კონტეინერებს და rollback-ს — გაშვება სამუშაო დღის შუაგულში ხდება შესაძლებელი.

staging პროდაქშენს არ ჰგავს

ტესტი გადის, პროდაქშენში კი ვარდება. ვასწორებთ გარემოების აღწერას ისე, რომ განსხვავება მხოლოდ მონაცემები და პარამეტრები იყოს.

ღრუბლის ხარჯი უკონტროლოდ იზრდება

ვზომავთ, რა მოიხმარს რესურსს, ვშლით მიტოვებულ გარემოებს და ვამატებთ ხარჯის ხედვას დაშბორდზე — გადაწყვეტილება ციფრზე დგება.

ხშირი კითხვები

ხშირი კითხვები

Kubernetes გვჭირდება?

ხშირად არა. რამდენიმე სერვისისთვის Docker Compose ან მსუბუქი პლატფორმა უფრო იაფია და ნაკლებ ოპერირებას მოითხოვს. Kubernetes მაშინ ჯობია, როცა მასშტაბი და გუნდი მას ინახავს.

ჩვენს ღრუბელში მუშაობთ თუ თქვენსში?

ორივეში. საჯარო ღრუბელი, ჩვენი დატაცენტრი ან თქვენივე აღჭურვილობა — pipeline და აღწერა იგივე რჩება, იცვლება მხოლოდ სამიზნე.

ჩვენს დეველოპერებს ჩაანაცვლებთ?

არა. ვაწყობთ ინფრასტრუქტურას და pipeline-ს, რომ თქვენმა გუნდმა უფრო სწრაფად გაუშვას. თუ პროდუქტის შემუშავებაც გჭირდებათ, ეს ცალკე სერვისია.

დაგვიწერეთ თქვენი ინფრასტრუქტურის შესახებ