Yaklaşık 100 Satırlık Bash ile Uygulanan Docker: Bocker (2015)

 (github.com/p8952)
6 puan yazan GN⁺ 2024-11-24 | 1 yorum | WhatsApp'ta paylaş
  • Bocker, Docker’ı yaklaşık 100 satırlık Bash ile uygulayan bir proje; imaj pull etme, container run etme, logları görüntüleme, commit ve silme gibi Docker benzeri akışlar sunuyor
  • Çalıştırmak için btrfs-progs, curl, iproute2, iptables, libcgroup-tools, util-linux 2.25.2 veya üzeri, coreutils 7.5 veya üzeri gerekiyor; ayrıca /var/bocker altında bir btrfs dosya sistemi ve bridge0 ağ yapılandırması gerekli
  • README örneği, centos:7 imajını pull ettikten sonra container içinde komut çalıştırmayı, yum install -y wget sonucunu commit etmeyi ve sonraki çalıştırmada /usr/bin/wget’i doğrulamayı gösteriyor
  • Bocker root olarak çalışıyor ve ağ arayüzlerini, routing tablolarını, firewall kurallarını değiştirdiği için sanal makinede çalıştırılması öneriliyor; sistemde hasar oluşmayacağına dair garanti yok
  • Şu anda docker pull, images, ps, run, exec, logs, commit, rm/rmi, ağ özellikleri ve CGroups tabanlı kota uygulanmış durumda; ancak veri volume’leri, veri volume container’ları ve port forwarding henüz uygulanmamış

Bocker’ın amacı ve kapsamı

  • Bocker, Docker’ı yaklaşık 100 satırlık Bash ile uygulayan bir proje
  • README, Docker’a benzer komut akışını Bash tabanlı olarak gösteriyor; imaj yönetimi, container çalıştırma, log görüntüleme, değişiklikleri commit etme ve kaynak sınırlama gibi özellikleri içeriyor

Çalıştırma gereksinimleri

  • Çalıştırmak için gereken paketler şunlar

    • btrfs-progs

      • curl
      • iproute2
      • iptables
      • libcgroup-tools
      • util-linux 2.25.2 veya üzeri
      • coreutils 7.5 veya üzeri
      • Çoğu dağıtım yeterince güncel util-linux içermediğinden, util-linux 2.25 kaynak kodunu alıp doğrudan derlemeniz gerekebilir
      • Sistemde şu yapılandırmalar gerekli
      • /var/bocker altına mount edilmiş bir btrfs dosya sistemi
      • bridge0 adlı bir ağ bridge’i ve 10.0.0.1/24 IP’si
      • /proc/sys/net/ipv4/ip_forward üzerinde IP forwarding’in etkinleştirilmesi
      • Trafiği bridge0 üzerinden fiziksel arayüze yönlendiren firewall ayarları
      • Gerekli ortamı kolayca oluşturmak için Vagrantfile dahil edilmiş

Çalıştırırken dikkat edilmesi gerekenler

  • Gereksinimler karşılansa bile Bocker’ın sanal makinede çalıştırılması öneriliyor
  • Bocker root olarak çalışır ve şu öğeleri değiştirmesi gerekir
    • Ağ arayüzleri
    • Routing tabloları
    • Firewall kuralları
  • README, Bocker’ın sistemi bozmayacağını garanti edemediğini açıkça belirtiyor

Örnek kullanım akışı

  • bocker pull centos 7 ile centos:7 imajı alındığında img_42150 gibi bir imaj ID’si oluşturulur
  • bocker images, imaj ID’sini ve kaynağı gösterir
    • Örnek çıktı: img_42150, centos:7
  • bocker run img_42150 cat /etc/centos-release, container içinde CentOS sürüm bilgisini yazdırır
    • Örnek çıktı: CentOS Linux release 7.1.1503 (Core)
  • bocker ps, çalıştırılan container ID’sini ve komutu gösterir
  • bocker logs ps_42045, ilgili container’ın çıktı loglarını gösterir
  • bocker rm ps_42045, container’ı kaldırır
  • bocker run img_42150 which wget çalıştırıldığında ilk başta wget bulunmadığı sonucu çıkar
  • bocker run img_42150 yum install -y wget ile wget kurulduktan sonra, bocker commit ps_42018 img_42150 ile değişiklikler imaja yansıtılır
  • Daha sonra bocker run img_42150 which wget, /usr/bin/wget çıktısını verir

Kaynak sınırları ve CGroups

  • Bocker çalıştırma örneği, container’ın CGroups altına yerleştirildiğini gösteriyor
    • /proc/1/cgroup içinde memory:/ps_42152, cpuacct,cpu:/ps_42152 gibi öğeler görünür
  • Varsayılan CPU share ve bellek sınırı örnekleri şöyle
    • /sys/fs/cgroup/cpu/ps_42152/cpu.shares: 512
    • /sys/fs/cgroup/memory/ps_42152/memory.limit_in_bytes: 512000000
  • Kaynak sınırları ortam değişkenleriyle değiştirilebilir
    • BOCKER_CPU_SHARE=1024
    • BOCKER_MEM_LIMIT=1024
  • Değişiklikten sonraki örnek şu değerleri gösterir
    • CPU shares: 1024
    • memory limit: 1024000000

Uygulanan ve uygulanmayan özellikler

  • Şu anda uygulanan özellikler şunlar
    • docker build †
    • docker pull
    • docker images
    • docker ps
    • docker run
    • docker exec
    • docker logs
    • docker commit
    • docker rm / docker rmi

    • Networking

      • Quota Support / CGroups
      • † bocker init, docker build’in çok sınırlı bir uygulamasını sunar
      • Henüz uygulanmamış özellikler şunlar
      • Data Volume Containers
      • Data Volumes
      • Port Forwarding

Lisans

  • Bocker, GNU General Public License koşulları altında yeniden dağıtılabilen ve değiştirilebilen özgür yazılımdır
  • Lisans sürümü olarak Free Software Foundation tarafından yayımlanan GPL v3 veya daha sonraki bir sürüm seçilebilir
  • Program yararlı olması umuduyla dağıtılır; ancak satılabilirlik veya belirli bir amaca uygunluk konusunda zımni garanti de yoktur

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-24
Hacker News yorumları

  • proot ile benzer bir şey yapmıştım; adı Bag [1] idi ve sanırım bunu Docker alternatifi diye tanımlamamıştım
    cgroups ile ilgisi yoktu, komut satırı arayüzü de Docker’dan farklıydı. Arka planı şuydu: internet sansürünü ve derin paket incelemesini aşmak için normal HTML trafiği gibi görünen bir proxy zinciri yapmıştım; bunun her yerde sürekli çalışması gerekiyordu ama bunu Android native uygulamasına port etmek istemiyordum
    Termux’ta çalıştırmak istiyordum; o dönemde Termux’ta JDK/JRE yoktu ve proot ile bir Arch Linux ortamı başlatınca JDK kullanabiliyordum. Termux içindeki Arch ortamı genel olarak daha kullanışlıydı; farklı yapılandırmalara sahip tek kullanımlık ortamlar oluşturup silmek ve ardından proot ile içine girip yalnızca tek bir komut çalıştırmak da betikle kolayca otomatikleştirilebiliyordu. Bu yüzden, nakliye konteynerinden çok daha küçük bir şey anlamında adını bag.sh koydum
    İlginçtir, bag.sh içinde 5 yıldır dokunulmamış bir yol haritası/TODO da duruyor. Mobil ekranda yazdığım ve kaydırmadan görmek istediğim için çoğu satır 40 sütuna göre hizalanmış durumda
    [1]: https://github.com/hkoosha/bag

    • Sanırım bu tür hikâyeler epey çoktur. VM’in uygun olmadığı bir durumda birden fazla bileşeni tek bir ortam olarak paketlemem gerektiği için chroot ve deb-bootstrap kullanıp makeself ile bir kurulum programı yapmıştım
      /opt içine gerekli yazılımları ve MySQL gibi bağımlılıkları koyan küçük bir Debian yaptım; oldukça iyi çalıştı ve bunu yaptığım şirket 2016 civarında satın alınana kadar kullanıldı. Daha genel olarak, büyük bir uygulamanın kaba saba bir sürümünü kendin uygulamaya çalışmanın iç işleyişi öğrenmenin en iyi yollarından biri olduğunu düşünüyorum
    • Betikte önemli birkaç tırnak işaretini atlamış gibisiniz. shellcheck çalıştırmak iyi olurdu
      mkdir -p $(dirname "$2")
    • 8 inçlik tableti yatay çevirince gerçekten okunabilir boyutta ancak 80x22 civarı elde edebiliyordum
      Deri ceketin iç cebine rahatça sığan yaklaşık 10 inçlik bir Bluetooth klavyeyle birlikte, çantasız evden çıksam bile yakındaki bir bira bahçesinin köşesine oturup kod yazabiliyorum. Şaşırtıcı derecede üretken de olabiliyor; sanırım dizüstüne kıyasla alışıldık dikkat dağıtıcılara geçişte biraz daha fazla sürtünme olduğu için, biradan bir yudum alıp koda bakmayı sürdürüyorum

  • Böyle şeyleri seviyorum. Minimal Bash ile yapılmış şeyleri hep sevmişimdir
    Yaklaşık 10 yıl önce Docker, Mesos gibi dağıtık altyapıları tanıtmak için düzenlediğim bir hackathon’da yaptığım, 40 satırlık Bash’ten oluşan küme içi yük dengeleyici kavram kanıtı da var: https://github.com/cell-os/metal-cell/blob/master/discovery/...
    Muhtemelen kaybettim ama yedeklilik ve dağıtıklık sağlayan, ters SSH tüneli tabanlı bir colo-to-cloud aktarım aracı da vardı. Shell Fu vb. yerlerde bu tür koleksiyonlar iyi derlenmiş: https://www.shell-fu.org/

    • shell-fu.org harika, ama başka kullanıcıların yorumlarını da görmek isterdim

  • Docker’ın büyük bir kısmının bu kadar basitçe yeniden uygulanabilmesi, Docker şirketinin karşılaştığı ve hâlâ karşılaştığı en büyük sorun. Çünkü temelde kernel özelliklerini birbirine bağlayan yapıştırıcı koda daha yakın
    Docker’ın gerçekten değer kattığı yer yalnızca Docker Hub değil, Docker for Windows ve Mac. Geliştirme makinesinde Docker çalıştırmak için VirtualBox ve Vagrant’ı elle kurcalamaya kıyasla entegre deneyimin çok daha iyi olması önemli

    • Rancher Desktop da pratik bir seçenek ve ücretsiz. Docker’ın yeni lisansı yürürlüğe girdikten sonra, benim iş yerim dâhil pek çok yer ona geçti
      Kişisel olarak Docker’ın asıl sihrinin Docker/OCI imaj formatı olduğunu düşünüyorum. Önbellekleme ve konteyner imajlarının dağıtımını çok iyi ele alan bir yaklaşım; hâlâ “tam” VM ile iş akışını ayıran temel unsur da bu
    • Mac’te Docker Desktop kısıtları çok olan, yetkileri de yetersiz karmakarışık bir şey. Mac’te Docker CLI ve Colima kullanmanın da yetki kısıtları var ama en azından saçma lisans ve Docker GUI’den kaçınabiliyorsunuz
      Windows’ta Docker’ı WSL içinde kullanabiliyorsunuz ve gayet iyi çalışıyor. Neden Docker Desktop kullanıldığını anlamakta zorlanıyorum
    • macOS’ta sadece Colima kullanıyorum; çok daha iyi bir deneyim ve çok daha hafif
    • Hayır, Docker’ın CloudRun, Render, Fly gibi PaaS’leri önce yapıp şirketlere pahalıya satması gerekiyordu
      Bunun yerine düzgün ve güvenilir çalışmayan, yarım yamalak Docker Swarm’ı yaptılar ve Kubernetes tarafından hızla geriye itildiler
    • Popüler ve para kazandıran sistemler arasında “kolayca” yeniden uygulanabilecek çok şey var. Docker’ın değerinin Docker imajlarında olduğunu düşünmüştüm; sanırım Docker zaten böyle kullanılmıyor mu?
      Benim kullanım biçimim sadece birkaç yıl önce bir yazılımı derlemek için birinin sanal derleme ortamını almak olmuştu

  • Depoda “henüz uygulanmadı”, “TODO”, “çalışılıyor” gibi ifadeler var ve son commit’in yıllar önce olduğunu görmek hoşuma gidiyor
    Kendi koduma serpiştirdiğim TODO’lara geri dönmüyor olmam konusunda içim biraz rahatlıyor. Yazarı küçümsemek değil niyetim, sadece teselli oluyor

    • İyi bir nokta. Hiç küçümseme değil; bu durumu normalleştirmesi güzel
      Ücretsiz, gönüllü, hobi kodunda sırf herkese açık diye yapmak zorundaymış gibi bir baskı hissedersen kod yazmak daha az keyifli olur ve normalde yayımlayacağın kodu da yayımlamamaya başlayabilirsin
    • Çoğu projenin, belki de tüm projelerin hiç bitmediğini düşünüyorum. Ne zaman duracağını bilmek önemli
    • Bence iyi. Bir şey basbayağı tamamlanabilir; her zaman yığınla bir sonraki fikir olmak zorunda değil, ama genelde hep bir sonraki fikir vardır
      Her zaman bir sonraki fikir varsa, tanım gereği bitmemiş TODO’lar da hep kalmak zorundadır. Aslında tüm projelerin normal durumu böyle olmalı
    • Bir projeye başlarken “hedef olmayanlar”ı, yani akla gelen ama bilinçli olarak uygulanmayacak özellikleri düşünmeye zaman ayırmak iyi olur
      Kapsam sınırlarını net çizmek tamamen sorun değil ve çoğu zaman faydalı. Böylece yan yollara sapıp projenin sonsuza dek “tamamlanmamış” gibi hissettirmesine kapılmazsın
    • Hiç sorun değil. Program istediğim işi yapıyor ve benim işim bittiyse geliştirmeyi durdururum. Yazılım benim hobim değil

  • lazydocker’ın Docker Desktop’a harika bir alternatif olarak hâlâ anılmamış olmasına şaşırdım. Linux/macOS/Windows’ta kullanılabiliyor [1]
    Oldukça özellikli bir terminal UI ve SSH üzerinden çalıştırılabilmesi gibi bir avantajı da var
    [1] https://github.com/jesseduffield/lazydocker

    • Kelimenin tam anlamıyla birkaç gün önce paylaşılmıştı: https://news.ycombinator.com/item?id=42214873
    • Lazydocker kesinlikle ilginç görünüyor, ama bir açık kaynak projesinin README.md dosyasında bambaşka bir alandaki ürün için kendini tanıtan reklam bulunması biraz fazla
      En azından ben böyle bir şeyi ilk kez gördüm. Böyle reklamların GitHub’ın hizmet şartları ya da kabul edilebilir kullanım politikası kapsamında izinli olup olmadığını da merak ediyorum

  • Bocker’ın neden bu kadar sık ana sayfaya çıktığını merak ediyorum. 2024’te Docker hâlâ bu kadar tartışmalı mı?
    Docker’ın gerçekten faydalı olan şeyi, esasen yazılım dağıtımını ve “her yerde kolayca çalıştırma”yı getirdiğini neden kabul etmediklerini anlamıyorum

    • Bu sadece Docker’ın nasıl çalıştığını görmek için bir öğrenme aracı
      Docker, zaten var olan çekirdek teknolojilerinin bir bileşimi. Namespace’ler, cgroups, union dosya sistemi ve muhtemelen birkaç şey daha
    • Sık sık ana sayfaya çıkmasının nedeni, birçok kişinin Docker’ın inanılmaz karmaşık bir şey olduğunu düşünmesi; oysa en temel seviyede aslında oldukça zarif ve anlaşılabilir olması
      Bu yüzden ilginç ve fiilen mükemmel bir HN hikâyesi
    • Ana sayfaya Docker’ı küçümsemek için çıkmıyor olabilir; Docker’ın faydalı olduğunu görüp nasıl çalıştığını öğrenmek isteyenler olabilir. Bocker bu teknolojilere açılan bir kapı olabilir
    • Şirkette uzun CI sürecini kısaltmak için overlayfs’i alıp gösterdim; hız artışına herkes şaşırdı
      Birkaç kişiye demo yaptıktan sonra, onların aslında doğrudan / kullanabileceğini ya da benim onlara Docker’ı getirmiş olabileceğimi fark ettim

  • Başka anneden kardeş gibi bir örnek de https://bastillebsd.org/
    Bastille, Docker’da görebileceğiniz birçok yapıyı shell ile kullanarak FreeBSD jail’lerini yönetiyor. Bağımlılıkları çok az olduğu için BSD’deki diğer jail yönetim yazılımlarından daha çok hoşuma gidiyor

    • cbsd de epey etkileyici: shttps://www.bsdstore.ru/en/about.html
      Ancak CLI/TUI tabanlı bir araç olmasına rağmen “azami aşırılık”a yakın bir çözüm. Bu aralar yalnızca FreeBSD’nin varsayılan kurulumuyla jail oluşturma ve yönetme adımlarından geçiyorum; ama bu sadece geçici bir aşama
      Her şeyin nasıl birbirine oturduğunu kafama yeterince kazıyıp hata ayıklamada kendime güvenene kadar böyle yapacağım; sonra da aklı başında biri gibi taşları birbirine vurmayı bırakıp daha yüksek seviyeli araçlara döneceğim
    • Doğru. Yaklaşık 100 satırlık bir shell betiği için oldukça fazla değer katıyor
      Ama adının neden Bastille olduğunu anlamam biraz zaman aldı. La Bastille, Yüz Yıl Savaşı sırasında Paris’i İngiliz saldırılarına karşı savunmak için inşa edilmiş bir kaleydi ve sonradan hapishaneye dönüştürüldü

  • “Çoğu dağıtım yeterince güncel bir util-linux sürümü sağlamadığından, kaynak kodu buradan alıp kendiniz derlemeniz gerekecek” kısmında dikkatli olmak gerek
    Varsayılan kurulum öneki /usr/bin olduğu için kurulum süreci mevcut mount komutunun üzerine, var olmayan kütüphaneler isteyen bir sürüm yazabilir. Bu da bir sonraki açılışta çekirdeğin dosya sistemini salt okunur bağlamasına yol açar

    • /usr/local/bin olmalı

  • Günlük kullanım için iyi değil ama Docker’ın ne olduğu ve nasıl çalıştığı hakkında fikir veriyor
    Linux’ta Docker temelde gösterişli bir chroot’tur

    • macOS/Windows vb. üzerinde Docker, temelde bir Linux VM içindeki gösterişli bir chroot’tur

  • Eğlenceli bir bilgi: Docker Bash ile başladı, sonra Python’a taşındı ve en sonunda Go’da karar kıldı
    Ayrıca 2013’teki bir Docker buluşmasında biri Bash ile bir Docker klonu yazmıştı. İnsanlar öğrenmek istiyor; umarım böyle şeyler yardımcı olur