Linux Temelleri: DevOps ve Bulut için Bilmen Gereken Her Şey

DevOps için Linux temelleri, bulut ve otomasyon dünyasına adım atan herkesin ilk durağı olmalı. Docker'ı, Kubernetes'i, Terraform'u veya bir CI/CD pipeline'ını gerçekten anlamak istiyorsan işin özünde her zaman Linux vardır: konteynerlerin çalıştığı çekirdek, sunucuların açıldığı işletim sistemi, betiklerin koştuğu kabuk hep Linux'tur. Bu yazıda DevOps için Linux bilgisini sıfırdan, gerçek komutlarla ve pratik örneklerle ele alıyoruz — dosya sistemi hiyerarşisinden izinlere, süreç yönetiminden systemd servislerine ve uzak sunucu yönetimine kadar. Amaç, bir terminal ekranı açıldığında kendini kaybolmuş değil, evinde hissetmen.

Neden Linux DevOps'un temelidir?

İnternetteki sunucuların büyük çoğunluğu Linux üzerinde çalışır. Web sunucuları, veritabanları, konteyner platformları, CI koşucuları (runner) ve bulut sağlayıcıların altyapısı Linux tabanlıdır. Bir DevOps mühendisi olarak günün büyük bölümünü ya bir Linux sunucusuna bağlanarak ya da Linux üzerinde koşan araçları yöneterek geçirirsin. Bu yüzden Linux'u "öğrenilecek bir konu" olarak değil, üzerinde çalışacağın zemin olarak düşünmek gerekir.

• Konteynerler Linux'tur: Docker ve container'lar; namespaces, cgroups ve chroot gibi Linux çekirdek özellikleri üzerine kurulur. Konteyneri anlamak, Linux'u anlamaktan geçer.
• Bulut sunucuları Linux'tur: AWS EC2, GCP Compute Engine ve Azure VM'lerinin varsayılanı Linux imajlarıdır.
• Otomasyon kabukta yaşar: Ansible, shell script'leri ve pipeline adımları Linux komutlarını çalıştırır.
• Sorun giderme terminalde biter: Bir servis çöktüğünde log'a bakmak, süreci bulmak ve portu kontrol etmek için Linux araçlarına ihtiyacın olur.

Dağıtımlar: Ubuntu, Debian ve RHEL ailesi

"Linux" aslında çekirdeğin (kernel) adıdır; bizim kullandığımız ise bu çekirdeğin etrafına araçlar, paket yöneticisi ve varsayılan yapılandırmalar eklenmiş dağıtımlardır (distribution / distro). DevOps dünyasında en sık iki aileyle karşılaşırsın: Debian ailesi (Debian, Ubuntu) ve Red Hat ailesi (RHEL, CentOS, Rocky Linux, Fedora, Amazon Linux).

İki aile arasındaki en görünür fark paket yöneticisidir: Debian ailesi apt kullanırken Red Hat ailesi dnf/yum kullanır. Komutların büyük çoğunluğu (ls, cd, grep, ps, systemctl) her dağıtımda aynıdır. Başlangıç için Ubuntu en pratik seçim: geniş topluluk, bol dokümantasyon ve bulut sağlayıcılarda birinci sınıf destek.

Dosya sistemi hiyerarşisi (FHS)

Windows'ta sürücüler C:\, D:\ diye ayrılır; Linux'ta ise tek bir kök dizin (/) vardır ve her şey onun altında bir ağaç gibi dallanır. Bu yapı Filesystem Hierarchy Standard (FHS) ile standartlaştırılmıştır ve dağıtımdan dağıtıma büyük ölçüde tutarlıdır. Nerede ne bulunacağını bilmek, sunucuda kaybolmamanın anahtarıdır.

• / — kök dizin; her şeyin başladığı yer.
• /etc — sistem geneli yapılandırma dosyaları (ör. /etc/ssh/sshd_config, /etc/hosts).
• /home — normal kullanıcıların ev dizinleri (/home/oguz).
• /root — root kullanıcısının ev dizini.
• /var — değişken veri: log'lar (/var/log), veritabanları, kuyruklar.
• /usr — kullanıcı programları ve kütüphaneleri (/usr/bin, /usr/local).
• /bin, /sbin — temel sistem komutları.
• /tmp — geçici dosyalar; yeniden başlatmada temizlenir.
• /opt — üçüncü parti / opsiyonel yazılımlar.
• /proc, /sys — çekirdek ve süreçlerin sanal dosya sistemleri (bellekte, diskte değil).

$ ls /
bin   dev  home  lib    mnt  proc  run   srv  tmp  var
boot  etc  lib64  media  opt  root  sbin  sys  usr
 
$ ls -la /var/log
drwxr-xr-x  2 root root  4096 Jul 21 09:12 .
drwxr-xr-x 14 root root  4096 Jul 10 08:00 ..
-rw-r-----  1 syslog adm  84213 Jul 21 09:30 syslog
-rw-r-----  1 syslog adm  12044 Jul 21 09:28 auth.log

Kabuk (shell) ve temel gezinme komutları

Kabuk, yazdığın komutları yorumlayıp çekirdeğe ileten programdır. En yaygın kabuk bash (Bourne Again Shell), modern sistemlerde ise zsh de sık görülür. Terminal açıldığında karşına gelen $ işareti (root için #) komut beklendiğini gösterir. İşe her gün kullanacağın gezinme komutlarıyla başlayalım.

$ pwd
/home/oguz
 
$ cd /var/log
 
$ pwd
/var/log
 
$ ls -lh
total 96K
-rw-r----- 1 syslog adm  83K Jul 21 09:30 syslog
-rw-r----- 1 syslog adm  12K Jul 21 09:28 auth.log
 
$ cd ~        # ev dizinine dön
$ cd -        # bir önceki dizine dön

• pwd — bulunduğun dizini yazdırır (print working directory).
• cd <dizin> — dizin değiştirir; cd .. bir üst dizine, cd ~ ev dizinine gider.
• ls — dizin içeriğini listeler; -l uzun format, -a gizli dosyalar, -h okunabilir boyut.
• clear — ekranı temizler (Ctrl+L ile aynı).
• history — daha önce çalıştırdığın komutları gösterir; yukarı ok tuşu geçmişte gezinir.

Dosya ve dizin işlemleri

Günlük işlerin çoğu dosya oluşturmak, kopyalamak, taşımak, silmek ve içeriğini görmekten ibarettir. Bu komutları akıcı kullanmak, terminalde geçirdiğin zamanı dramatik biçimde kısaltır.

$ mkdir -p proje/config          # iç içe dizinleri tek seferde oluştur
$ touch proje/config/app.yaml    # boş dosya oluştur
$ cp app.yaml app.yaml.bak       # kopyala
$ mv eski.txt yeni.txt           # taşı / yeniden adlandır
$ rm gecici.log                  # sil
$ rm -r proje/                   # dizini içeriğiyle sil
 
$ cat /etc/hostname              # dosya içeriğini yazdır
$ less /var/log/syslog           # sayfalı görüntüle (q ile çık)
$ head -n 20 app.log             # ilk 20 satır
$ tail -n 50 app.log             # son 50 satır
$ tail -f app.log                # canlı takip (yeni satırları anlık gösterir)

Metin işleme ise DevOps'un günlük ekmeğidir. grep ile arama yapar, | (pipe) ile bir komutun çıktısını başka bir komuta beslersin. Bu "küçük araçları zincirleme" felsefesi, Unix'in gücünün kalbidir.

$ grep "error" /var/log/syslog          # "error" geçen satırlar
$ grep -i "error" app.log                # büyük/küçük harf duyarsız
$ grep -rn "TODO" src/                   # dizinde özyinelemeli + satır no
$ cat access.log | grep "500" | wc -l    # 500 hatası kaç kez geçmiş?
$ ps aux | grep nginx | grep -v grep     # nginx süreçleri (grep'in kendisi hariç)

Dosya izinleri ve sahiplik (chmod / chown)

Linux çok kullanıcılı bir sistemdir; her dosyanın bir sahibi, bir grubu ve üç kademeli izin seti vardır. ls -l çıktısındaki -rwxr-xr-- gibi ifadeler tam olarak bunu anlatır. İzinleri anlamak, hem güvenlik hem de "neden bu betik çalışmıyor?" sorularının çözümüdür.

$ ls -l deploy.sh
-rwxr-xr-- 1 oguz devops 512 Jul 21 10:00 deploy.sh
  │└┬┘└┬┘└┬┘   │    │
  │ │  │  │    │    └─ grup (devops)
  │ │  │  │    └────── sahip (oguz)
  │ │  │  └─────────── diğerleri: r-- (yalnızca okuma)
  │ │  └────────────── grup: r-x (oku + çalıştır)
  │ └───────────────── sahip: rwx (oku + yaz + çalıştır)
  └─────────────────── dosya tipi: - (normal dosya), d (dizin), l (link)

İzinler üç kimlik için tanımlanır — sahip (user), grup (group), diğerleri (other) — ve her biri için üç yetki vardır: oku (r=4), yaz (w=2), çalıştır (x=1). Bu sayıları toplayarak sekizlik (octal) notasyonu elde edersin.

$ chmod 755 deploy.sh        # sahip rwx, grup r-x, diğer r-x
$ chmod +x script.sh         # çalıştırma izni ekle
$ chmod 600 id_rsa           # SSH özel anahtarı: yalnızca sahip okur/yazar
$ chown oguz:devops app.log  # sahip=oguz, grup=devops yap
$ chown -R www-data:www-data /var/www   # dizini özyinelemeli sahiplen

Kullanıcı yönetimi ve sudo

Üretim sunucularında root olarak sürekli çalışmak hem tehlikeli hem de kötü bir alışkanlıktır. Bunun yerine normal bir kullanıcı olarak çalışıp, yükseltilmiş yetki gerektiren komutları sudo ile çalıştırırsın. Bu, hem kaza sonucu hasarı sınırlar hem de kimin ne yaptığının log'lanmasını sağlar.

$ whoami
oguz
$ id
uid=1000(oguz) gid=1000(oguz) groups=1000(oguz),27(sudo),999(docker)
 
$ sudo useradd -m -s /bin/bash deploy   # yeni kullanıcı + ev dizini
$ sudo passwd deploy                    # parola belirle
$ sudo usermod -aG docker deploy        # deploy'u docker grubuna ekle
$ sudo systemctl restart nginx          # yetki gerektiren komut

• whoami — hangi kullanıcı olduğunu gösterir.
• id — kullanıcı ve grup kimliklerini (uid/gid) listeler.
• sudo <komut> — komutu root yetkisiyle çalıştırır.
• su - <kullanıcı> — başka bir kullanıcıya geçiş yapar.
• usermod -aG <grup> <kullanıcı> — kullanıcıyı bir gruba ekler (ör. docker grubu).

Süreç yönetimi (ps / top / kill)

Her çalışan program bir süreçtir (process) ve benzersiz bir PID (process ID) ile tanımlanır. Bir uygulamanın CPU'yu tükettiğini, takıldığını ya da hiç çalışmadığını anlamak için süreçleri gözlemlemen gerekir. Bu, sorun gidermenin (troubleshooting) merkezindedir.

$ ps aux | head -3
USER  PID  %CPU %MEM   VSZ   RSS TTY  STAT START  TIME COMMAND
root    1   0.0  0.1 168920 11284 ?   Ss   09:00  0:02 /sbin/init
www     842 2.3  4.1 998244 82112 ?   Sl   09:12  0:45 nginx: worker
 
$ top          # canlı, sıralı süreç izleme (q ile çık)
$ htop         # renkli/interaktif alternatif (kurulu ise)
 
$ kill 842          # sürece nazikçe dur sinyali gönder (SIGTERM)
$ kill -9 842       # zorla sonlandır (SIGKILL, son çare)
$ pkill nginx       # isimle sonlandır

Paket yönetimi (apt / dnf)

Yazılım kurmak, güncellemek ve kaldırmak paket yöneticisinin işidir. Debian ailesinde apt, Red Hat ailesinde dnf/yum kullanılır. Paket yöneticisi bağımlılıkları da otomatik çözer, bu yüzden yazılımı elle indirip derlemekten çok daha güvenlidir.

# Ubuntu / Debian
$ sudo apt update              # paket listesini yenile
$ sudo apt upgrade -y          # kurulu paketleri güncelle
$ sudo apt install nginx -y    # paket kur
$ sudo apt remove nginx        # paketi kaldır
$ apt search redis             # paket ara
 
# RHEL / Rocky / Amazon Linux
$ sudo dnf install nginx -y
$ sudo dnf update -y
$ sudo dnf remove nginx

Servisler: systemd, systemctl ve journalctl

Modern Linux dağıtımlarında servisleri (arka planda çalışan uygulamalar: nginx, sshd, docker, veritabanları) yöneten sistem systemd'dir. systemctl ile servisleri başlatır/durdurur, journalctl ile log'larını okursun. Bir DevOps mühendisinin en sık kullandığı komutlar arasındadır.

$ sudo systemctl status nginx
● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
     Active: active (running) since Mon 2026-07-21 09:12:03 UTC
 
$ sudo systemctl start nginx      # başlat
$ sudo systemctl stop nginx       # durdur
$ sudo systemctl restart nginx    # yeniden başlat
$ sudo systemctl reload nginx     # yapılandırmayı yeniden yükle (kesintisiz)
$ sudo systemctl enable nginx     # açılışta otomatik başlat
$ sudo systemctl disable nginx    # otomatik başlatmayı kapat

Bir servis "active (running)" değil de "failed" gösteriyorsa, ilk yapman gereken log'lara bakmaktır. journalctl systemd'nin merkezi günlük deposunu sorgular.

$ sudo journalctl -u nginx              # nginx servisinin tüm log'ları
$ sudo journalctl -u nginx -n 50        # son 50 satır
$ sudo journalctl -u nginx -f           # canlı takip
$ sudo journalctl -u nginx --since "10 min ago"
$ sudo journalctl -p err -b             # bu açılıştaki hata seviyesi log'lar

Ağ araçları (curl / ss / ping / dig)

Dağıtık sistemlerde "neden birbirine bağlanamıyorlar?" en sık sorulan sorudur. Ağ araçları, bir servisin dinleyip dinlemediğini, bir portun açık olup olmadığını ve DNS'in doğru çözülüp çözülmediğini anlamanı sağlar.

$ curl -I https://cloudpuz.com        # HTTP başlıklarını göster (durum kodu vb.)
HTTP/2 200
content-type: text/html; charset=utf-8
 
$ curl -s http://localhost:8080/health   # bir servisin sağlık ucunu test et
{"status":"ok"}
 
$ ss -tlnp                            # dinlenen TCP portları (netstat'ın modern hâli)
State  Recv-Q Send-Q Local Address:Port
LISTEN 0      511          0.0.0.0:80
LISTEN 0      128          0.0.0.0:22
 
$ ping -c 4 8.8.8.8                   # bağlantı/gecikme testi
$ dig +short cloudpuz.com             # DNS A kaydı çözümü
$ nslookup cloudpuz.com               # DNS sorgusu (alternatif)

Log inceleme ve sorun giderme

Sorun giderme, DevOps'un belki de en değerli becerisidir ve neredeyse tamamı log okumaya dayanır. Yukarıda öğrendiğimiz grep, tail -f, journalctl ve less araçlarını bir araya getirerek bir olayı adım adım kovalarsın. Tüm bu pratik komutları tek bir yerde, bol örnekle derlediğimiz DevOps için Linux komutları rehberi bu bölümün doğal devamıdır — orayı bir başvuru kaynağı gibi yanında tut.

1. 1**Belirtiyi netleştir:** Servis mi çöktü, yavaş mı, yoksa 5xx hata mı dönüyor? `systemctl status` ve `curl -I` ile durumu doğrula.
2. 2**Log'a in:** `journalctl -u <servis> -n 100` ya da `tail -f /var/log/<uygulama>.log` ile en son ne olduğuna bak.
3. 3**Kalıbı ara:** `grep -i error`, `grep -i fail`, `grep -i timeout` ile hata satırlarını süz.
4. 4**Kaynağı kontrol et:** `top`/`htop` ile CPU/bellek, `df -h` ile disk doluluğu, `free -h` ile RAM'e bak — çoğu çökme dolu diskten kaynaklanır.
5. 5**Ağı doğrula:** `ss -tlnp` ile servisin gerçekten dinlediğini, `curl localhost:<port>` ile yanıt verdiğini teyit et.
6. 6**Değişikliği izole et:** "Dün çalışıyordu" ise son deploy, son yapılandırma değişikliği ya da son güncellemeye odaklan.

$ df -h                    # disk kullanımı (dolu disk = gizli sorun kaynağı)
Filesystem  Size Used Avail Use% Mounted on
/dev/root    50G   47G   3.0G  95% /
 
$ free -h                  # bellek durumu
              total  used  free  available
Mem:           7.8G  6.1G  340M      1.2G
 
$ du -sh /var/log/*        # hangi log dosyası şişmiş?
$ grep -i "out of memory" /var/log/syslog   # OOM killer devreye girmiş mi?

SSH ve uzak sunucu yönetimi

DevOps'ta çalışacağın sunucular neredeyse hiçbir zaman önündeki makine değildir; bulutta, uzak bir veri merkezindedir. Onlara SSH (Secure Shell) ile bağlanırsın. SSH şifreli bir kanal açar; parola yerine anahtar çiftiyle (public/private key) kimlik doğrulamak hem daha güvenli hem de otomasyona uygundur.

$ ssh-keygen -t ed25519 -C "oguz@cloudpuz"   # anahtar çifti üret
$ ssh-copy-id oguz@203.0.113.10              # public anahtarı sunucuya kopyala
$ ssh oguz@203.0.113.10                      # bağlan
$ ssh -i ~/.ssh/id_ed25519 oguz@sunucu       # belirli anahtarla bağlan
$ ssh -p 2222 oguz@sunucu                    # farklı port
 
# Dosya transferi
$ scp ./app.tar.gz oguz@sunucu:/tmp/         # yerelden uzağa kopyala
$ scp oguz@sunucu:/var/log/app.log ./        # uzaktan yerele çek

Uzak sunuculara dosya taşırken sıklıkla arşiv oluşturursun. tar bu işin standart aracıdır: birden çok dosyayı tek bir pakette birleştirir ve isteğe bağlı sıkıştırır.

$ tar -czf yedek.tar.gz /var/www/site   # oluştur (c) + gzip (z) + dosya (f)
$ tar -xzf yedek.tar.gz                 # çıkar (x)
$ tar -tzf yedek.tar.gz                 # içeriğini listele (t)

Kabuk betikleri (bash) temeli

Aynı komut dizisini tekrar tekrar yazıyorsan, onu bir kabuk betiğine (shell script) dönüştürme zamanı gelmiştir. Bash betikleri; deploy adımlarını, yedekleri ve sağlık kontrollerini otomatikleştirmenin en hızlı yoludur. İyi bir bash temeli, ileride yazacağın CI/CD pipeline adımlarının da özüdür.

#!/usr/bin/env bash
set -euo pipefail   # hata olursa dur, tanımsız değişkende dur, pipe hatasını yakala

APP_DIR="/var/www/site"
BACKUP="/tmp/site-$(date +%F).tar.gz"

echo "Yedek alınıyor: ${BACKUP}"
tar -czf "${BACKUP}" "${APP_DIR}"

if [ -f "${BACKUP}" ]; then
  echo "Yedek başarılı ✓"
else
  echo "Yedek BAŞARISIZ" >&2
  exit 1
fi

for service in nginx docker; do
  if systemctl is-active --quiet "${service}"; then
    echo "${service}: çalışıyor"
  else
    echo "${service}: DURMUŞ" >&2
  fi
done

• #!/usr/bin/env bash — shebang; betiğin hangi yorumlayıcıyla çalışacağını söyler.
• set -euo pipefail — profesyonel betiklerin ilk satırı; sessiz hataları görünür kılar.
• $(...) — komut ikamesi; bir komutun çıktısını değişkene alır.
• if [ ... ]; then ... fi — koşul; dosya var mı, servis çalışıyor mu gibi kontroller.
• for ... do ... done — döngü; birden çok öğe üzerinde tekrar.
• >&2 — çıktıyı hata akışına (stderr) yönlendir; exit 1 başarısızlığı bildirir.

Buradan sonra: Docker, Kubernetes, CI/CD ve Terraform

Linux temellerini oturttuğunda, DevOps araç zincirinin geri kalanı çok daha anlaşılır hâle gelir — çünkü hepsi Linux üzerine kuruludur. İşte doğal ilerleme sırası ve her adımın nereye oturduğu:

• Konteynerleştirme: Uygulamalarını taşınabilir imajlara paketle. Docker nedir ve temelleri ile başla; Docker'ın Linux namespaces ve cgroups üzerine kurulu olduğunu artık biliyorsun.
• Orkestrasyon: Yüzlerce konteyneri ölçeklemek için Kubernetes'e sıfırdan başlangıç rehberine geç; kubectl komutlarının Linux terminal alışkanlıklarına ne kadar benzediğini göreceksin.
• Otomasyon: Kod her değiştiğinde otomatik test ve dağıtım için CI/CD nedir kavramını öğren, ardından GitHub Actions ile ilk pipeline'ını kur — pipeline adımlarının aslında bash komutları olduğunu fark edeceksin.
• Altyapı kodu: Sunucuları elle değil kodla yönetmek için Terraform nedir rehberine bak.
• Bulut zemini: Tüm bunların üzerinde çalıştığı katmanı anlamak için bulut bilişim nedir yazısı iyi bir çerçeve sunar.

Bu becerileri bir kariyere nasıl dönüştüreceğini merak ediyorsan, tüm bu parçaları bir yol haritasında birleştiren DevOps engineer nasıl olunur rehberi senin ana rotan olacak. Linux, bu rotanın ilk ve en sağlam basamağıdır.

Sıkça Sorulan Sorular

DevOps için Linux öğrenmek şart mı?

Evet, kesinlikle. Sunucuların, konteynerlerin ve bulut altyapısının büyük çoğunluğu Linux üzerinde çalışır. Docker, Kubernetes ve CI/CD araçlarını yüzeysel değil gerçekten kullanabilmek için Linux dosya sistemi, izinler, süreçler ve kabuk komutlarına hakim olman gerekir. Linux, DevOps kariyerinin pazarlık edilemez temelidir.

Hangi Linux dağıtımıyla başlamalıyım?

Yeni başlayanlar için Ubuntu en pratik seçim: geniş topluluk desteği, bol dokümantasyon ve tüm bulut sağlayıcılarda birinci sınıf destek sunar. Kurumsal ortamlara yöneleceksen ileride RHEL ailesini (Rocky Linux, Amazon Linux) de öğrenmen faydalı olur; ancak temel komutlar iki ailede de aynıdır, bu yüzden birinden diğerine geçmek kolaydır.

Windows kullanıyorum, Linux'u nasıl pratik yapabilirim?

Birkaç kolay yol var: Windows üzerinde WSL2 (Windows Subsystem for Linux) ile tam bir Ubuntu terminaline dakikalar içinde kavuşabilirsin. Alternatif olarak bir bulut sağlayıcıdan (çoğu ücretsiz katman sunar) küçük bir sanal sunucu açıp SSH ile bağlanabilir ya da VirtualBox/Multipass ile yerelde sanal makine çalıştırabilirsin. Cloudpuz'un tarayıcı içi laboratuvarları ise kurulum gerektirmeden pratik yapmanı sağlar.

chmod 755 ile 644 arasındaki fark nedir?

755 (rwxr-xr-x) sahibe tüm yetkileri, gruba ve diğerlerine oku+çalıştır verir — çalıştırılabilir betikler ve dizinler için idealdir. 644 (rw-r--r--) sahibe oku+yaz, diğerlerine yalnızca oku verir ve çalıştırma yetkisi içermez — bu yüzden yapılandırma dosyaları, HTML ve düz metin dosyaları için uygundur. Kural: çalıştırılabilir dosyalar/dizinler 755, veri/yapılandırma dosyaları 644.

systemctl ve journalctl ne zaman kullanılır?

systemctl servisleri yönetmek için kullanılır: başlatmak, durdurmak, yeniden başlatmak, açılışta otomatik başlamasını sağlamak ve durumunu görmek. journalctl ise o servislerin ürettiği log'ları okumak içindir. Pratikte ikisi birlikte çalışır: systemctl status ile bir sorun görürsün, journalctl -u <servis> ile detayına inersin.

Linux temellerini öğrenmek ne kadar sürer?

Bu yazıdaki komutları rahatça kullanabilecek düzeye günde 30-60 dakika pratikle yaklaşık 2-4 haftada ulaşabilirsin. Gerçek akıcılık ise onları bir işi bitirmek için kullandıkça gelir — bu yüzden Linux'u tek başına değil, Docker ve CI/CD gibi projelerin içinde öğrenmek en verimli yoldur. Ezberlemeye değil, tekrar tekrar kullanmaya odaklan.

Linux temelleri, DevOps ve bulut yolculuğunun sağlam zeminidir; bu zemin olmadan üstüne kurulan Docker, Kubernetes ve otomasyon araçları hep biraz sihir gibi, biraz da kırılgan kalır. Bu yazıda dosya sisteminden izinlere, süreçlerden servislere ve uzak sunucu yönetimine kadar günlük olarak kullanacağın her aracı gerçek komutlarla gördün. Şimdi sıra pratikte: bir terminal aç, buradaki komutları kendi elinle çalıştır ve ardından DevOps için Linux komutları rehberiyle reflekslerini pekiştir. Terminalde ne kadar çok zaman geçirirsen, DevOps o kadar erişilebilir bir dünyaya dönüşecek.