DevOps-ის სწავლა: საიდან დავიწყოთ და რა გამოვტოვოთ

თუ გინდა სერვერები მართო და პროგრამული უზრუნველყოფა გაუშვა, ისწავლე ამ თანმიმდევრობით: Linux და shell, შემდეგ ერთი პატარა სერვერი, რომელსაც ცარიელი მანქანიდან მუშა, მონიტორინგიან, backup-ებიან აპლიკაციამდე მიიყვან, შემდეგ systemd, Nginx, Docker და deploy pipeline - სწორედ ამ რიგით, თითოეული ჩაანაცვლებს რაღაცას, რაც უკვე ხელით გაგიკეთებია. Kubernetes, service mesh-ები და multi-cloud მოგვიანებით მოდის, თუ საერთოდ მოდის. DevOps-ზე უმეტესობა იმიტომ ჩერდება, რომ ამ სიის თავიდან დაიწყო და არა ბოლოდან.

ჩვენ ვმართავთ RE:NODE ჰოსტინგ პლატფორმას, რომელიც 500-ზე მეტი კლიენტისთვის 1 200-ზე მეტ სერვერს ატარებს. პლატფორმის მართვა გვაჩვენებს, რომელი უნარები ინახავს ფლოტს ღამით ფეხზე, ადამიანების სწავლის გავრცელებული ხერხები კი - რომელ მათგანს ტოვებენ ხოლმე. ეს წერილი არის გზა, რომელსაც ნებისმიერს მივცემდით, ვინც ნულიდან იწყებს, მიზეზებითურთ, რადგან სწორედ მიზეზები გაძლევს საშუალებას, შემდეგი ინსტრუმენტი თავად შეაფასო.

თანმიმდევრობა და რატომ ეს თანმიმდევრობა#

პრინციპი მარტივია: არასოდეს ავტომატიზირო ის, რაც ხელით არ გაგიკეთებია. ყველა DevOps ინსტრუმენტი ხელით შესასრულებელი საქმის გარსია - პროცესის გაშვება, მოთხოვნის მარშრუტიზაცია, ფაილების სერვერზე გადატანა, შემოწმება, მუშაობს თუ არა რამე. თუ ჯერ გარსს ისწავლი, tutorial-ს გაჰყვები, მაგრამ პირველივე გაფუჭებისას ქვეშ არაფერი გაქვს, რასაც დაეყრდნობი.

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

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

Linux და shell ყველაფერზე ადრე#

ამ სფეროში თითქმის ყველაფერი Linux-ზე მუშაობს და თითქმის ყოველი პრობლემა, რომელსაც გამართავ, Linux-ის პრობლემაა კოსტიუმში. container, რომელიც არ ირთვება, ხშირად უფლებების პრობლემაა, დაკარგული ფაილი ან უკვე დაკავებული port. ნელი deploy ჩვეულებრივ დისკი ან ქსელია. "შემთხვევითი" ჩავარდნა ხშირად kernel-ის out-of-memory killer-ია. ამის დანახვა შეუძლებელია, თუ shell ისეთი ადგილია, სადაც მხოლოდ ბრძანებების ჩასასმელად შედიხარ.

რაში უნდა გრძნობდეს ადამიანი თავს თავისუფლად, container-ს რომ შეეხება:

• ნავიგაცია და ფაილების კითხვა: cd, ls -la, cat, less, tail -f, grep, find.
• უფლებები და მფლობელობა: რას ნიშნავს rwx, chmod, chown, რატომ ვერ კითხულობს www-data-ს სახელით გაშვებული სერვისი root-ის ფაილს, რომელსაც 600 რეჟიმი აქვს.
• პროცესები: ps aux, top ან htop, kill, რა არის სიგნალი, განსხვავება SIGTERM-სა და SIGKILL-ს შორის.
• დისკი და მეხსიერება: df -h, du -sh, free -h და რატომ შეიძლება "დისკი სავსეა" ნიშნავდეს "inode-ები გათავდა".
• ქსელის საფუძვლები: ss -tlnp იმის სანახავად, რა უსმენს, curl -v იმის სანახავად, რას აკეთებს მოთხოვნა სინამდვილეში, dig იმის სანახავად, რაზე ირეზოლვება სახელი.
• log-ები: journalctl -u name, /var/log და ჩვევა, ვარაუდამდე ბოლო 50 ხაზი წაიკითხო.

# The five commands to answer before anyone says "it doesn't work"$ systemctl status myapp          # is it running, and what did it last say$ journalctl -u myapp -n 50       # the last 50 lines it logged$ ss -tlnp                        # what is listening, on which port, as which process$ df -h && free -h                # disk and memory, the two boring killers$ curl -v http://127.0.0.1:3000/  # does it answer locally, before blaming DNS

ყველაზე მნიშვნელოვანი shell-ის უნარი flag-ების დამახსოვრება არ არის. ეს არის ჩვევა, მანქანას ჰკითხო და არ იგარაუდო. დამწყებები ხშირად სამ რამეს ერთდროულად ცვლიან, რთავენ თავიდან და იმედოვნებენ. უკეთესი წესია: ერთი ცვლილება, ერთი restart, წაიკითხე log. ათ წუთს უფრო ნელია, დანარჩენ კარიერაში კი ბევრად სწრაფი. უფრო გრძელი მითითება არის Linux-ის ბრძანებები სერვერის ადმინებისთვის.

ისწავლე Bash იმდენად, რომ ოც ხაზიანი სკრიპტი დაწერო ცვლადით, if-ით, ციკლით და თავში set -euo pipefail-ით. Bash-ში კარგი არ გჭირდება იყო. გჭირდება შეგეძლოს სხვების მიერ სერვერებზე დატოვებული სკრიპტების წაკითხვა, რადგან მათ ბევრს ნახავ.

ერთი VPS თავიდან ბოლომდე#

ყველაზე სასარგებლო სავარჯიშო ასეთია: იქირავე ერთი პატარა სერვერი და მიიყვანე ახალი ინსტალაციიდან რეალურ აპლიკაციამდე, რომელსაც ვინმეს ანახვებდი. არა cluster, არა სამი პროვაიდერი, ერთი მანქანა. მთელი გზის ერთხელ გავლა გასწავლის, როგორ უკავშირდება ნაწილები ერთმანეთს, რასაც ცალ-ცალკე სწავლა ვერ გასწავლის.

გზა, თანმიმდევრობით:

1. შედი SSH-ით, შექმენი ჩვეულებრივი მომხმარებელი sudo-თი და გადადი გასაღებით შესვლაზე. გამორთე password-ით შესვლა და root-ით შესვლა მას შემდეგ, რაც გასაღები იმუშავებს - არა უწინ, თორემ თავს გამოიკეტავ.
2. ჩართე firewall, რომელიც ჯერ SSH-ს უშვებს, შემდეგ მხოლოდ საჭირო port-ებს. Ubuntu-ზე ეს არის ufw allow OpenSSH, შემდეგ ufw enable.
3. ჩართე უსაფრთხოების ავტომატური განახლებები და ისწავლე, როგორ გადატვირთო მანქანა შიშის გარეშე.
4. დააყენე runtime და გაუშვი აპლიკაცია ხელით, წინა პლანზე, სანამ არ იმუშავებს.
5. გახადე ის systemd სერვისი.
6. დაუყენე წინ Nginx დომენითა და სერტიფიკატით.
7. დაამატე backup, uptime შემოწმება და დისკის ალერტი.
8. ჩაიწერე ყოველი ნაბიჯი, შემდეგ გაანადგურე სერვერი და აღადგინე შენი ჩანაწერებით.

მერვე ნაბიჯს ხალხი ტოვებს და ის ყველაზე მეტს ასწავლის. პირველ აღდგენაზე აღმოაჩენ პარამეტრს, რომელიც შეცვალე და დაგავიწყდა, პაკეტს, რომელიც გამართვისას დააყენე, ფაილს, რომელიც შუაღამეს /etc-ში შეასწორე. ეს უფსკრული "რა მგონია, რომ არის სერვერზე" და "რა არის სინამდვილეში სერვერზე" შორის სწორედ ის პრობლემაა, რომლის გადასაჭრელად არსებობს კონფიგურაციის მართვა და container-ები. ერთხელ იგრძენი და გაიგებ, რატომ არსებობს ეს ინსტრუმენტები, და არა მხოლოდ მათი სინტაქსი ისწავლი.

პირველი ნაბიჯები დეტალურად არის აღწერილი წერილებში პირველი საათი ახალ VDS-ზე და SSH გასაღებები და გამაგრება.

როგორ ივარჯიშო იაფ სერვერზე

ბევრი არ გჭირდება. 1-2 GB RAM-ისა და ერთი-ორი ბირთვის მქონე მანქანა სასწავლო მიზნებისთვის კომფორტულად ატარებს პატარა ვებ აპლიკაციას, Nginx-ს, მონაცემთა ბაზასა და მონიტორინგის agent-ს. ზომაზე მეტად მნიშვნელოვანია:

• ის უნდა იყოს რეალური საჯარო სერვერი. ვირტუალური მანქანა ლეპტოპზე shell-ისთვის კარგია, მაგრამ მალავს იმას, რაც გტკენს: DNS, სერტიფიკატები, ინტერნეტის წინაშე მდგარი firewall, ბოტები, რომლებიც მისამართის გამოჩენიდან წუთებში SSH password-ებს სცდიან.
• ის უნდა იყოს ერთჯერადი. მიიჩნიე როგორც რაღაც, რასაც წაშლი და თავიდან ააგებ. თუ გეშინია მისი გატეხვის, მასზე ვერაფერს ისწავლი.
• მიეცი დომენი. იაფი დომენი, რომელიც A ჩანაწერით მიუთითებს მასზე, საშუალებას გაძლევს TLS, redirect-ები და virtual host-ები სწორად ივარჯიშო და არა გვერდის ავლით.
• დააყენე ბიუჯეტის ალერტი ან ფიქსირებული ფასის გეგმა. cloud ანგარიშები წუთობრივი ბილინგითა და ლიმიტის გარეშე სასწავლად ცუდი ადგილია, რადგან ძვირი შეცდომა ისაა, რომელსაც ვერ ამჩნევ.

გატეხე განზრახ. შეავსე დისკი fallocate -l-ით და ნახე, რა ვარდება პირველი. დახოცე აპლიკაცია kill -9-ით და შეამოწმე, აბრუნებს თუ არა systemd. გააჩერე Nginx და ნახე, რას ამბობს ბრაუზერი. წაშალე მონაცემთა ბაზა და აღადგინე. თითოეული მათგანი რეალური ჩავარდნაა, რომელსაც მოგვიანებით შეხვდები, და სავარჯიშო მანქანაზე მასთან შეხვედრა უფასოა.

systemd: ნაწილი, რომელსაც ყველა ტოვებს#

დამწყებები ხშირად პირდაპირ გადადიან "ჩემს ტერმინალში მუშაობს"-დან "Docker-ში მუშაობს"-ზე და გამოტოვებენ ფენას, რომელიც Linux მანქანაზე პროცესებს რეალურად ცოცხლად ინახავს. ეს შეცდომაა, რადგან თუნდაც ყველაფერი container-ებში გაუშვა, თავად container runtime systemd სერვისია და გამართვის უნარები პირდაპირ გადადის.

unit ფაილი მოკლეა და მისი ხელით დაწერა გასწავლის, რას ნიშნავს "პროდაქშენში მუშაობა": ფიქსირებული მომხმარებელი, სამუშაო საქაღალდე, გარემო, restart პოლიტიკა და log-ები, რომლებიც სადმე მიდის, სადაც წაიკითხავ.

[Unit]Description=My appAfter=network-online.targetWants=network-online.target[Service]User=myappWorkingDirectory=/opt/myappEnvironmentFile=/etc/myapp/envExecStart=/usr/bin/node /opt/myapp/server.jsRestart=on-failureRestartSec=5[Install]WantedBy=multi-user.target

შემდეგ systemctl daemon-reload, systemctl enable --now myapp და journalctl -u myapp -f მის დასაკვირვებლად. თუ გესმის, რატომ არის Restart=on-failure, რატომ არ მუშაობს აპლიკაცია root-ით და რატომ ცხოვრობს საიდუმლოებები მკაცრი უფლებებით EnvironmentFile-ში და არა თავად unit-ში, პროდაქშენზე მეტი გესმის, ვიდრე ბევრს, ვინც CV-ში Kubernetes-ს ჩამოთვლის. სრული განხილვა არის წერილში systemd სერვისები შენი აპლიკაციებისთვის.

Nginx ყველაფრის წინ#

შემდეგი ფენა reverse proxy-ა. შენი აპლიკაცია უსმენს 127.0.0.1:3000-ზე, ხოლო Nginx უსმენს 80-ე და 443-ე port-ებზე, წყვეტს TLS-ს, ემსახურება სტატიკურ ფაილებს და დანარჩენს გადაუგზავნის. ეს ვებ-ის უმეტესობის უკან მდგარი პატერნია, და მისი ხელით სწავლა მომავალში შეხვედრილ ყველა მართვად load balancer-სა და ingress controller-ს გასაგებს ხდის.

server {    listen 80;    server_name app.example.com;    location / {        proxy_pass http://127.0.0.1:3000;        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header X-Forwarded-Proto $scheme;    }}

აიღე სერტიფიკატი Certbot-ით, შეამოწმე განახლება certbot renew --dry-run-ით და ყოველ reload-მდე გაუშვი nginx -t. რისი გაგებაც ღირს და არა უბრალოდ კოპირება: რატომ უნდა უსმენდეს აპლიკაცია localhost-ზე და არა 0.0.0.0-ზე, რისთვის არის forwarded header-ები და რატომ აჩვენებს შენი აპლიკაციის log-ები 127.0.0.1-ს ყოველი სტუმრისთვის, სანამ proxy-ს ნდობას არ ეტყვი. Nginx reverse proxy-ის გზამკვლევი უფრო შორს მიდის, WebSocket-ებისა და timeout-ების ჩათვლით.

Docker, როცა უკვე იცი, რას ცვლის#

Docker არის ადგილი, სადაც ყველაზე მეტი დაბნეულობაა, და თითქმის ყველა მისი ძალიან ადრე სწავლიდან მოდის. თუ უკვე გაგიშვია აპლიკაცია როგორც systemd სერვისი Nginx-ის უკან, Docker-ის ადგილის გაგება ადვილია: image არის ფაილებისა და runtime-ის დაპაკეტებული ვერსია, რომელიც ხელით დააყენე, container არის პროცესი, რომელსაც systemd ატარებდა, volume არის მონაცემთა საქაღალდე, რომლის backup-იც უნდა გახსენებოდა, ხოლო გამოქვეყნებული port არის listen ხაზი, რომელიც უკვე გესმის.

რა უნდა აიღოს Docker-იდან ამ ეტაპზე ადამიანმა, ვინც სწავლობს:

• დაწერე Dockerfile საკუთარი აპლიკაციისთვის და არა მხოლოდ სხვების image-ები გამოიყენე.
• გაიგე ფენები იმდენად, რომ ფაილი ისე დაალაგო, რომ დამოკიდებულებები cache-დან იკითხებოდეს.
• ისწავლე, რომ container-ის ფაილური სისტემა იკარგება და ყველაფერი მნიშვნელოვანი volume-შია.
• გამოიყენე Docker Compose აპლიკაციისა და მისი მონაცემთა ბაზის ერთად გასაშვებად, მონაცემებისთვის დასახელებული volume-ით.
• გამოაქვეყნე port-ები განზრახ და იცოდე, რომ Docker-ის გამოქვეყნებულმა port-ებმა შეიძლება იმავე ჰოსტზე ufw-ის წესები გვერდი აუარონ, რადგან Docker საკუთარ iptables წესებს წერს.

services:  app:    build: .    restart: unless-stopped    env_file: .env    ports:      - "127.0.0.1:3000:3000"    depends_on:      - db  db:    image: postgres:16    restart: unless-stopped    environment:      POSTGRES_PASSWORD_FILE: /run/secrets/db_password    volumes:      - dbdata:/var/lib/postgresql/data    secrets:      - db_passwordvolumes:  dbdata:secrets:  db_password:    file: ./db_password.txt

შეამჩნიე 127.0.0.1: გამოქვეყნებული port-ის წინ. მის გარეშე აპლიკაცია ინტერნეტიდან პირდაპირ ხელმისაწვდომია, Nginx-ისა და firewall-ის გვერდის ავლით, რომელიც გეგონა, რომ გაქვს. ეს ერთი დეტალი კარგი ტესტია იმისა, ვინმემ Docker ისწავლა თუ უბრალოდ გადაიწერა. მეტი - Docker VDS-ზე და Docker Compose პატარა stack-ებისთვის.

CI/CD: ავტომატიზირე ის, რასაც უკვე ხელით აკეთებ#

ამ დროისთვის რამდენჯერმე გაქვს ხელით deploy გაკეთებული - ამოიღე კოდი, დააყენე დამოკიდებულებები, build, სერვისის restart. ეს ხელით თანმიმდევრობა შენი pipeline-ია. CI/CD არის მისი ფაილში ჩაწერა, რომ მანქანამ ყოველ ჯერზე ერთნაირად გაუშვას, წინ ტესტებით, რათა გატეხილი commit სერვერამდე მისვლამდე გაჩერდეს.

დაიწყე ყველაზე პატარა პატიოსანი pipeline-ით: გაუშვი ტესტები ყოველ push-ზე და დეპლოი გააკეთე main branch-ზე, როცა ისინი გაივლიან. GitHub Actions სწავლისთვის გონივრული ადგილია, რადგან უფასო ლიმიტი ამას მარტივად ფარავს და სინტაქსი ყველგანაა.

name: test-and-deployon:  push:    branches: [main]jobs:  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-node@v4        with:          node-version: 22      - run: npm ci      - run: npm test  deploy:    needs: test    runs-on: ubuntu-latest    steps:      - name: Deploy over SSH        run: |          echo "${{ secrets.DEPLOY_KEY }}" > key && chmod 600 key          ssh -i key -o StrictHostKeyChecking=accept-new \            deploy@${{ secrets.HOST }} 'cd /opt/myapp && ./deploy.sh'

deploy job უბრალოდ იძახებს deploy.sh-ს, რომელიც სერვერზე ცხოვრობს - იმავე სკრიპტს, რომელსაც ხელით გაუშვებდი. ეს უკეთესია, ვიდრე მთელი deploy workflow ფაილში ჩაიდოს, რადგან როცა pipeline ტყდება, შეგიძლია SSH-ით შეხვიდე და სკრიპტი თავად გაუშვა, რომ ნახო, რა ხდება. deploy გასაღებს მიეცი საკუთარი მომხმარებელი, რომელსაც წვდომა მხოლოდ ამ ერთ საქაღალდეზე აქვს.

ორ რამეზე ადრევე ღირს ყურადღების გამახვილება. პირველი, deploy უნდა იყოს განმეორებადი: ზედიზედ ორჯერ გაშვება უვნებელი უნდა იყოს. მეორე, უკან დასაბრუნებელი გზა უნდა არსებობდეს: შეინახე წინა რელიზი ან წინა image tag, რომ rollback იყოს ერთი ბრძანება და არა არქეოლოგიური პროექტი. RE:NODE-ზე ორკესტრაცია საშუალო deploy-ს ხუთ წუთზე ნაკლებამდე ამცირებს, და სისწრაფე ნაკლებად მნიშვნელოვანია, ვიდრე ის, რომ ყოველი ნაბიჯი ყოველ ჯერზე ერთნაირია - სწორედ ეს ხდის მის ხშირად კეთებას უსაფრთხოს.

მონიტორინგი და backup-ები პირველივე deploy-ში უნდა იყოს#

ეს არასასიამოვნო ნაწილია. სასწავლო გზების უმეტესობა მონიტორინგსა და backup-ებს მოწინავე თემებად თვლის, რომლებიც "მოგვიანებით" უნდა დაემატოს. მოგვიანებით ჩვეულებრივ ნიშნავს მას შემდეგ, რაც პირველად რამე დაიკარგება. ჩვენ მათ პირველი deploy-ის ნაწილად მივიჩნევთ, რადგან სერვისი ორივეს გარეშე დემოა და არა სერვისი.

მინიმუმი პატარაა:

backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. ტესტი მარტივია: აიღე გუშინ ღამის მონაცემთა ბაზის dump, აღადგინე ახალ მანქანაზე და გაუშვი აპლიკაცია მის წინააღმდეგ. თუ ამას შენი ჩანაწერებიდან ვერ აკეთებ, backup-ები ჯერ არ გაქვს. დავუშვათ, node-ის დისკი ღამის სამ საათზე ივსება - სასარგებლო კითხვებია: მიაღწია თუ არა ალერტმა ადამიანს შევსებამდე და არსებობს თუ არა ის მონაცემები, რაც შევსებამდე იყო, სადმე, რაც ის დისკი არ არის.

მონიტორინგს საპირისპირო გაუმართაობა აქვს. დამწყებები ხშირად აყენებენ დაფას ორასი გრაფიკით და ალერტების გარეშე, რაც დეკორაციაა. დაიწყე სამი-ოთხი ალერტით, რომელთაგან თითოეული ნიშნავს "ადამიანმა ახლავე რამე უნდა გააკეთოს", და მეტი დაამატე მხოლოდ მაშინ, როცა ინციდენტი ხარვეზს გაჩვენებს. დასამახსოვრებელი წესი ასეთია: ალერტი, რომელზეც არავინ რეაგირებს, უნდა წაიშალოს და არა დადუმდეს. იხილე მონიტორინგი, რომელიც რაღაცას გეუბნება და backup-ები, რომლებიც მართლა აღდგება.

რა გამოტოვო დასაწყისში#

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

Kubernetes-ს პირდაპირი სიტყვა ეკუთვნის, რადგან სწორედ მას უნდათ დამწყებებს ყველაზე ხშირად დაწყება. ის კარგი ინსტრუმენტია container-ების ბევრ მანქანაზე განსათავსებლად. მაგრამ მასში ყოველი ცნება - pod-ები, სერვისები, ingress, persistent volume-ები, probe-ები, საიდუმლოებები - აბსტრაქციაა რაღაცაზე უფრო ადრეული ეტაპებიდან: პროცესი, port, reverse proxy, დისკი, health check, გარემოს ფაილი. თუ Kubernetes-ს პირველად ისწავლი, აბსტრაქციებს ისწავლი იმის გარეშე, რასაც ისინი აბსტრაგირებენ, და გამართვა გამოცნობა ხდება. თუ ერთი VPS-ის, Docker-ისა და Nginx-ის შემდეგ ისწავლი, უმეტესობა იკითხება როგორც "აჰა, ეს ის არის, რაც უკვე გავაკეთე, YAML-ში გამოცხადებული".

არ ვამბობთ, რომ Kubernetes ცუდია ან რომ არასოდეს დაგჭირდება. ვამბობთ, რომ ერთი აპლიკაციისთვის ერთ-ორ სერვერზე ეს დიდი მექანიზმია, რომელიც იცავს პრობლემებისგან, რომლებიც არ გაქვს, და რომ მისი პირველად სწავლა ანელებს.

მცდარი წარმოდგენები, რომლებიც დამწყებებს ხშირად მოაქვთ#

ეს არის შაბლონები, რომლებიც საკმარისად გავრცელებულია, რომ დასაწყისშივე აღინიშნოს, და არა ისტორიები კონკრეტულ ადამიანზე.

• "DevOps არის ინსტრუმენტების ნაკრები." ეს მუშაობის გზაა: ადამიანები, რომლებიც პროგრამას წერენ, პასუხისმგებელნი არიან იმაზეც, როგორ მუშაობს ის, და ყველაფერი, რაც ორჯერ კეთდება, ავტომატიზირდება. ინსტრუმენტები რამდენიმე წელიწადში ერთხელ იცვლება. ჩვევები არა.
• "თუ ჩემს მანქანაზე მუშაობს, პრობლემა სერვერშია." განსხვავება ჩვეულებრივ კონფიგურაციაშია, ვერსიებში, გარემოს ცვლადებში ან ფაილების გზებში. ამ განსხვავების პოვნა არის სამუშაო.
• "container-ები ნაგულისხმევად უსაფრთხოა." container, რომელიც root-ით მუშაობს, გამოქვეყნებული port-ითა და მიმაგრებული ჰოსტის საქაღალდით, იზოლირებული არ არის იმ გაგებით, რომელსაც მნიშვნელობა აქვს. container-ები პირველ რიგში შეფუთვაა.
• "მეტი ინსტრუმენტი უფრო პროფესიონალურია." საუკეთესო სისტემები მოსაწყენია: ცოტა მოძრავი ნაწილი, თითოეული გაგებული. ყოველი დამატებული ინსტრუმენტი რაღაცაა, რასაც განახლება, მონიტორინგი და გამართვა სჭირდება.
• "root ჩემს სერვერზე წესრიგშია." წესრიგშია, სანამ დაუცველი აპლიკაცია root-ით არ გადასცემს თავდამსხმელს მთელ მანქანას. ცალკე მომხმარებლები არაფერი ღირს.
• "backup-ებს პროვაიდერი აკეთებს." ზოგჯერ. გაარკვიე ზუსტად, რას აკოპირებს, სად ინახავს და როგორ მუშაობს აღდგენა, სანამ დაგჭირდება.
• "ბრძანებები უნდა დავიმახსოვრო." უნდა იცოდე, რა არის შესაძლებელი და სად ეძებო. man გვერდებისა და log-ების კითხვა არის უნარი. დამახსოვრება გამოყენებას მოსდევს.

ყველაზე ძვირი მცდარი წარმოდგენა ყველაზე ჩუმია: რომ გაგება ყურებით მოდის. კურსები, ვიდეოები და tutorial-ები სასარგებლოა, მაგრამ ამ ყველაფრიდან არაფერი რჩება, სანამ რეალური სერვერი არ გაგიტეხია და თავად არ გაგიმართავს. სამიზნე თანაფარდობა გაცილებით მეტი დროა ტერმინალში, ვიდრე სლაიდების წინ.

რას გვიჩვენებს ჰოსტინგ პლატფორმის მართვა თანმიმდევრობაზე#

RE:NODE-ის მართვა ნიშნავს ავტომატიზებულ provisioning-ს, scaling-სა და აღდგენას ათეულობით node-სა და 30+ სერვისზე, RBAC-ით, მონიტორინგით, backup-ის ავტომატიზაციითა და ინციდენტებზე რეაგირებით ზემოდან. არცერთი მათგანი რთული ინსტრუმენტებით არ დაწყებულა. დაიწყო ხელით ნაბიჯებით, რომლებიც გასაგები იყო, რომლებიც გახდა სკრიპტები, რომლებიც გახდა სერვისები, რომლებიც გახდა ორკესტრაცია. ავტომატიზაციის ყოველი ფენა უსაფრთხო იყო ასაგებად, რადგან მის ქვეშ მდგარი ფენა უკვე გაგებული იყო.

სინამდვილეში ეს არის ამ წერილის მთელი არგუმენტი. თანმიმდევრობა თვითნებური არ არის. ყოველი ეტაპი წინას აქცევს რაღაცად, რაზეც შეგიძლია აღარ იფიქრო, და უსაფრთხოდ შეგიძლია აღარ იფიქრო მხოლოდ იმაზე, რაზეც ოდესღაც ყურადღებით იფიქრე. ვინც ზემოდან იწყებს, ქვემოთ უწევს ჩასვლა, როცა რამე ტყდება, ყველაზე ცუდ მომენტში. ვინც ქვემოდან იწყებს, საკუთარი tempo-ით მიდის ზემოთ.

AI coding agent-ებმა ეს უფრო მართალი გახადეს და არა ნაკლები. agent სიამოვნებით დაწერს Dockerfile-ს, unit ფაილს ან pipeline-ს წამებში. მაგრამ ის ფაილი სწორია თუ არა, უსაფრთხოა თუ არა და შენს სერვერს შეესაბამება თუ არა, ისევ ისეთი განსჯაა, რომელსაც მხოლოდ ის, ვისაც ფენები ესმის, გააკეთებს. უნარი, რომელიც იაფდება, კონფიგურაციის აკრეფაა. უნარი, რომელიც უფრო ფასეული ხდება, მისი წაკითხვაა.

FAQ#

რამდენი ხანი სჭირდება DevOps-ის საფუძვლების სწავლას?

ეს დამოკიდებულია იმაზე, რამდენ დროს ატარებ ტერმინალში და არა კითხვაში. ზემოთ ჩამოთვლილი ეტაპების რეალურ სერვერზე გავლა - ჩანაწერებით თავიდან აგებისა და backup-ის აღდგენის ჩათვლით - თვეების მდგრადი პრაქტიკაა და არა კვირების. Linux-ში კომფორტი ყველაზე ხანგრძლივი ეტაპია და ყოველ საათს ამართლებს.

უნდა ვიცოდე თუ არა პროგრამირება DevOps-ის სწავლამდე?

საკმარისი, რომ კოდი წაიკითხო და პატარა სკრიპტები დაწერო: Bash ბრძანებების ერთმანეთთან დასაკავშირებლად და ერთი ზოგადი ენა, მაგალითად Python, უფრო გრძელი საქმისთვის. ასევე უნდა გესმოდეს, როგორ არის აგებული და კონფიგურირებული აპლიკაციები, რომლებსაც აშვებ, რადგან დეპლოის პრობლემების უმეტესობა აპლიკაციასა და სერვერს შორის საზღვარზეა.

ჯერ AWS, Azure თუ Google Cloud უნდა ვისწავლო?

არცერთი ჯერ. ისწავლე ერთ უბრალო Linux სერვერზე, სადაც არაფერი დამალულია კონსოლის უკან. cloud პლატფორმები იმავე ბლოკებს ანაცვლებენ და ახვევენ - მანქანები, დისკები, ქსელები, firewall-ები, load balancer-ები - და ბევრად ადვილია მათი სწავლა, როცა იცი, რა არის ეს ბლოკები. cloud მოგვიანებით აირჩიე იმ სამუშაოს მიხედვით, რომელიც გინდა.

რა არის უფრო მნიშვნელოვანი ასასწავლად, Docker თუ Kubernetes?

Docker, დიდი უპირატესობით და Kubernetes-ზე ბევრად ადრე. თითქმის ყოველი თანამედროვე deploy სადმე იყენებს container image-ებს, და Kubernetes-ს სწორად ვერ გამოიყენებ image-ების, volume-ებისა და ქსელის გაგების გარეშე. ბევრი რეალური სისტემა კმაყოფილებით მუშაობს Docker Compose-ზე ერთ სერვერზე და მეტი არასოდეს სჭირდება.

შემიძლია DevOps-ზე ივარჯიშო სერვერის ფულის გადახდის გარეშე?

shell-ის, Docker-ისა და სკრიპტების სწავლა უფასოდ შეგიძლია ლოკალურ ვირტუალურ მანქანაში. რასაც ლოკალურად ვერ ივარჯიშებ, ის საჯარო ინტერნეტია: DNS, სერტიფიკატები, რეალური ტრაფიკის წინაშე მდგარი firewall და შესვლის მცდელობების მუდმივი ფონი. პატარა ფასიანი სერვერი ღირს, როცა თავიდან ბოლომდე ეტაპამდე მიხვალ.