Docker için WordPress geliştiricilerine giriş
Gereksinimler Bu öğreticiyi takip etmek için, bir Docker yüklediğinizden ve geliştirme bilgisayarınızda çalıştığınızdan emin olun (komut satırınızda $ Docker -V çalıştırarak doğrulama).Önceki bir Docker deneyimine sahip olmanıza gerek yok çünkü her şeyi en baştan açıklamaya çalışacağım.Bir sorunuz varsa, aşağıda yorum yapmaktan çekinmeyin.Son fakat en az değil, bir uyarı kelimesi;Docker Linux’ta orijinal desteklenirken, Windows ve Mac’te çalışmak için ek bir katman gerektirir (yüklerseniz, zaten biliyorsunuz).Bu sorun, Docker’ı şimdi kullanmanın avantajını biraz azaltır, ancak beta sürümüne erişimim olduğu için (ve burada da başvurabilirsiniz!), Bu sorunun yakında kaybolacağına ikna edebilirim.Sorun şu ki, hala bir sanal makine çalıştırmanız gerekiyor, ancak iyi kısmı sadece Boot2docker adı verilen küçük bir Linux dağıtımını çalıştırmak.
Peki liman işçisi nedir? Bir Docker’ın ne olduğunu anlamak için, (ve WordPress geliştiricilerinin demek istediğimiz) neredeyse her gün karşılaştığımız bazı sorunlara bakalım. Hepimiz kodumuzu diğer geliştiricilerle (veya birçoğuyla) paylaşmamız gereken bir durumda bulunduk. Kodumuzu GitHub’a ilettikten sonra (kullanıyorsunuz, git, değil mi?) Ve çalıştırmaya çalışırlar, işe yaramaz. Sorunun ne olduğu sorulduğunda, hepimiz bilinen bu ifadeyle cevap verdik: bu bilgisayarımda çalışıyor. İki geliştirici aynı proje üzerinde çalıştığında, bu büyük bir sorun gibi görünmüyor- birlikte oturuyorlar (veya neredeyse), sorunları çözüyorlar ve umarım belgeliyorlar. Ancak aynı projede çalışan 20 geliştirici olduğunda ne olur? Veya 50? İşler hızla kontrolden çıkabilir. Üretimle aynı. Kaç kez birkaç kod yazıyorsunuz, yerel olarak test ediyorsunuz, ancak üretim için kullanıldığında, ölümün beyaz ekranıyla karşılaşıyorsunuz? Şimdi aynı üretim ortamına başvuran 20 geliştiriciden oluşan bir ekip hayal edin. Zaman miktarı geliştirme yerine devOps için boşa harcanır. Bu, para miktarı çılgın olduğu anlamına gelir, çünkü birisi bu sorun için harcanan zamanı ödemek zorundadır. Geri adım atalım ve bu soruna neden olan bazı olası nedenleri görelim: – WordPress sürümleri (ve/veya eklentiler) Farklı – Farklı PHP sürümleri – Web sunucusunun farklı sürümleri (Apache/Nginx) – MySQL’in farklı sürümleri – İşletim sistemi farklı farklı sürümler Hiç – yapılandırma yukarıdakilerin tümünden farklıdır (bellek sınırı/CPU, modül yüklü)
Peki Docker masaya ne getirdi? Bir şey: tutarlılık. Bu, çevrenin çalıştığınız her yerde aynı olacağını garanti eder; Yerel olarak, 50 farklı bilgisayarda, CI ortamında (devam eden entegrasyon) veya üretimde – bu tam olarak aynı olacaktır, çünkü aynı ortamı ve kodu kullanacaktır. Bu sorunlar elbette yeni değil ve tutarsızlık sorununu azaltmak için en azından bir dereceye kadar deneyen alternatifler var: Vagrant. Tıpkı Docker gibi, bir maliyet gerektiren tutarlı bir ortam inşa etmek için bir tarif sağlar: Bu, en az bir sanal makine çalıştırmanızı gerektirir – bu bir docker gibi olmayan, tam bir Linux dağıtımdır, deneyeceğim sorunla Bu öğretici boyunca tanımlamak için. Bu sorunun ilkini göstermek için, birçok Docker öğreticisi bu diyagramı gösterir:
İlk bakışta, büyük bir fark gibi görünmüyor, bu yüzden size sistem kaynaklarını dikkate alan daha doğru bir diyagram göstereyim:
Ekstra katman artık masum görünmüyor değil mi? Ve aslında, sanal olmayan işletim sistemi/konuk, onu çalıştırmak için çok sayıda kilitli kaynak gerektirir ve her konuk işletim sistemi için doğru miktarı dikkatlice ayarlamazsanız kesinlikle bu kaynaklardan tükeneceksiniz. Ve kilitli olduğunda, konuk işletim sistemine CPU, RAM ve sabit sürücü alanlarının sayısını ayarladıktan sonra, konukların büyük veya küçük kullanıp kullanmadığına bakılmaksızın, ana bilgisayar bunu kullanamaz – bu kaynak dağıtılmaz.
Şimdi bir docker’ın kesilmiş bir tür sanal makine olduğunu ve yarı haklı olduğunuzu düşünebilirsiniz; Bu sanal iyi, ama bir makine değil, çevre. Sanal makinelerin fiziksel bir makine olduğunu düşündüğü yerlerde (sanalbox veya vmware füzyonu gibi sanallaştırma yazılımı aracılığıyla), Docker Container (hemen terminoloji hakkında daha fazla, budama VM linux olarak düşünün), ihtiyaç duyulan ve sadece herhangi bir kaynak için işletim sistemi ana bilgisayarına bağlı olarak Linux ortamını çalıştırmak için gereken minimumları içerir-sadece 5 megabayt disk alanı ve bellek geleneksel VM’den önemli ölçüde daha azdır. Masaya getirilen ikinci en büyük yararı anlamak için küçük bir gelişime bakalım (PHP veya WP değil, sadece genel gelişim). Orada – uygulanırsa – yaşam geliştiricisini daha kolay hale getiren ve katı adı verilen bir dizi ilke var. İlk prensip (tek sorumluluk ilkesi) ikinci en büyük fayda Docker’dır: Her Docker görüntüsü sadece bir şey ve bir şey yapmaktan sorumludur. Bir web sunucusuna mı ihtiyacınız var? Nginx’i al. Bir PHP tercümanına mı ihtiyacınız var? Bunun için bir resim var. Mysql? Kontrol.
Gerçekten de, aldığımız şey genellikle Docker’ın kendisi, Docker Swarm veya Kubernetes gibi birkaç üst düzey yazılım tarafından düzenlenen Docker kaplarından bazılarıdır, böylece birlikte iyi çalışabilirler. Bu serinin üçüncü yazısında Kubertetes’i derinlemesine tartışacağız. Tüm bu sorumlulukları içeren bir görüntü oluşturmak çok mümkün, ancak neden bundan kaçınmanız gerektiğini açıklamak için elimden geleni yapacağım. Şimdi ilk resmimiz Docker’ın ne olduğuna dair temel bir anlayışa sahip olduktan sonra, gelecekte WordPress sitemiz için kullanacağımız temel bir kazık (Linux, Nginx, MySQL, PHP) oluşturmaya çalışalım. Temel liman işçileri konteynırları, özellikle inşa etmeye gerek yoktur, bu yüzden ilk bölümümüz olarak Nginx’e odaklanalım. Yeni bir proje dizini oluşturun ve içinde index.html adlı bir dosya oluşturun ve aşağıdaki html snippet’ini girin:
Docker’dan merhaba dünya! : $ Docker Run -v $ (PWD):/usr/share/nginx/html -p 8080: 80 nginx (bu hatayı alırsanız: Docker: Docker Daemon’a bağlanamıyor. Bu, Docker motorunu yüklemediğiniz anlamına gelir Kabuğun içine ayarlar, $ değer “$ (Docker-Machine Env varsayılan)” çalıştırın
Docker’dan merhaba dünya! : $ Docker Run -v $ (PWD):/usr/share/nginx/html -p 8080: 80 nginx (bu hatayı alırsanız: Docker: Docker Daemon’a bağlanamıyor. Bu, Docker motorunu yüklemediğiniz anlamına gelir Kabuğun içine ayarlar, $ değer “$ (Docker-Machine Env varsayılan)” çalıştırın
Büyük olasılıkla yerel olarak bir Nginx resminiz olmadığından, Docker resmi depodan indirecek ve Volume parametresi ve girdiğiniz bağlantı noktası ile çalıştıracaktır. Koşup çalışmadığına dair bir gösterge vermeyecek (ilk başta, sıkışmış gibi görünüyor):
Bu yüzden tarayıcınızı açın ve http: // localhost: 8080’e (veya daha muhtemel bir liman işçi makinesi kullanıyorsanız, Localhost’u liman işçileriniz IP ile değiştirin) ve görünün, merhaba World’e gidin! . Süreci durdurmak için Ctrl + C’ye basın. Ne oldu? İlk başta küçük bir mucize gibi görünse de, aslında oldukça basitti; Docker İndirir Görüntüler (Nginx – Komuttaki Son Kelime), iki özel parametreli resmi içeren bir kap çalıştırır: Bu, Proje Dizinimizi ($ (PWD), mevcut veya mevcut çalışma dizini)/usr/share/ Nginx/html/html ve ayrıca 80 OS konuk bağlantı noktasını 8080 numaralı ana bilgisayarlarla eşleştirir – bu, iki karakter tarafından yapılan, bağlantı noktasını ve/veya hacmi ana bilgisayardan konteynere eşleştirir, bu nedenle 8080: 80, bağlantı noktası kullanmak anlamına gelir. 8080 ana bilgisayarda ve kapta 80 bağlantı noktasıyla eşler.
Not: Kurulum terimine aşina değilseniz: Bu, bilgisayarın bir kaptaki belirli bir yolun altına ses seviyesine (disk alanı bloğu) girdiği işlemdir. Bunu her gün USB tuşunu her taktığınızda veya bir DVD girdiğinizde deneyimlersiniz – işletim sistemi tarafından otomatik olarak yüklenir. Bu aynı zamanda USB tuşunu güvenli bir şekilde kaldırmanızın nedenidir: OS, hasarlı verilerle sonuçlanmaması için sürücüyü kaldırmalıdır!
Burada önemli bir not: Ana dizinini zaten orada olan yolun altındaki (ve dosyaları içeren) bir kap içine yüklerseniz, dizine yalnızca dizin yüklendiğinde erişilemeyeceği için kaybedilmez. Ve DVD analojilerini biraz daha uzun süre kullanmaya devam edersek, görüntü docker ve bir kapsayıcı arasındaki temel farkı anlamamıza yardımcı olabilir: Görüntü, paketlenmiş, dağıtılan ve değiştirilemeyen (DVD gibi) bir dosya sistemidir, konteynerler sağlarken Resmin çalıştırılabileceği izole ve çıplak Linux ortamları (DVD-ROM gibi, DVD’de olanı çalıştırmanıza izin veren bir bilgisayarın fiziksel bileşeni). Görüntüden değiştirilemeyen yönler çok ilginç hale getirir (değiştirilemez, yapıldıktan sonra resimdeki herhangi bir dosyayı değiştiremeyeceğiniz veya kalıcı olarak değiştiremeyeceğiniz anlamına gelir) -Bu gerçekten tek kullanımlık hale geldikleri için (aynı zamanda ePhmeral ile karşılaşabileceğiniz bir terim – aynı şey). Görüntüler tariften (DockerFile olarak adlandırılır) yeniden inşa edilebilir, böylece değişiklik yapmanız gerekiyorsa, sadece yeniden inşa edersiniz. Görüntüler ayrıca çok yararlı olan diğer sağlam ilkeleri de takip eder:
Açık kapak ilkesi. Bu, modifikasyon için kapalı bir kod parçasının ancak uzatmaya açık olduğunu belirtir. Aynı şekilde, görüntüler değiştirilemez, ancak genişletilebilir. PHP (veya bu durumda herhangi bir şey) hakkında hiçbir şey bilmediğimiz için, onu genişletme zamanı ve bunu yapıyoruz … Docker dosyası basit, DockerFile, Docker için bir dizi talimat içeren bir dosyadır. görüntü oluşturma siparişi. Bunu son resmimiz için bir plan olarak düşünün. Bir DockerFile’a koymanız gereken tek zorunlu talimattan talimat olarak adlandırılır; Bu, Docker’ın temel olarak hangi görüntüleri kullanmak istediğinizi bulmasını sağlar. Resmi Depo, hayal edebileceğiniz her türlü Linux lezzetinin veya yapılandırmanın görüntülerini depolar ve GitHub gibi bir kullanıcı adı/görüntü adı verilir: herhangi bir kullanıcı adı gerektirmeyen yetkili (her zaman isteğe bağlı etiketler) hariç. Bu nedenle, dockerFile adlı boş bir dosya oluşturun (uzantı olmadan) dizininizin yanında.html ve aşağıdaki iki satırı yapıştırın (bakım talimatlarını adınıza ve e-postanıza uyacak şekilde açıkça değiştirin): Nginx’ten: 1.10-alpine koruyucu Tomaz Tomaz
Özel görüntülerimiz resmi Alpine Image Nginx’e dayanacaktır. Alpine, sadece 5MB ağırlığındaki küçük bir Linux dağılımıdır ve Docker topluluğunda çok popüler hale gelir, çünkü APK adlı kutunun dışında bir paket kurulumu sağlar (Debian/Ubuntu’da Apt-Get’e benzer) ve çünkü küçük, yani İyi olan şey, çünkü sonunda görüntüleri (üretime) aktaracaksınız ve küçük olanları bir karşılaştırma olarak kullanmak mantıklıdır, çünkü ihtiyacımız olmayan daha fazla şey içerdiğinden yaklaşık ~ 200MB gerektirir. Sadece nginx ve bağımlılığa ihtiyacımız var. Bu, Docker’ı kullanmanın bir başka önemli yararıdır: Docker görüntüleri genişletilebilir. Ve ortaya çıkan görüntü de istediğiniz kadar genişletilebilir, bu yüzden gidip görüntünün kalıtımıyla tavşan deliğinin ne kadar derin olduğunu araştırırsanız, Nginx Dockerfile: 1.10-Alpine, Alpine’den: 3.3’ten. Öyleyse Alpine Dockerfile’ı kontrol edelim. Temelde tamamen boş bir görüntü olan, hiçbir şey yapmayan Scratch adlı bir görüntüden miras alındı, ancak temelde diğer tüm görüntülerin büyükannesidir, bu yüzden Scratch kelimesi Docker’da ayrılmıştır. Burada miras bizim durumumuzda nasıl görülüyor:
Bu öğreticide tartışmayacağımız, ancak bahsetmeye değer bir DockerFile talimatı CMD talimatıdır.Talimat, konteyner herhangi bir parametre olmadan başladığında çalıştırılacak varsayılan komutu ayarlar, ancak Nginx DockerFile bunu yaptı çünkü tanımlamamız gerekmez.Değilse, Nginx’i böyle komutlarla çalıştırmalıyız (örneğin, çalıştırmaya gerek yok): $ docker run -v $ (pwd):/usr/share/nginx/html -p 8080: 80 nginx nginx – G “Daemon Off;”(Nginx kelimesinin neden iki kez göründüğünü merak ediyorsanız: ilk örnek görüntünün adıdır, ikincisi -ve öyle -kapta çalıştırdığımız gerçek komuttur) Görüntümüzü oluşturmak için: $ Docker -t -wordpress oluştur.
Bu komut, geçerli dizinde DockerFile’ı okur ve görüntüyü benim-WordPress’e etiketler, çünkü yazması, işaretlemezsek Docker tarafından üretilen bir dizi rastgele karakterden daha kolaydır.Test etmek için, çalıştır: $ Docker Run -v $ (pwd):/usr/share/nginx/html -p 8080: 80 benim -wordpress çok fazla değişiklik değil, ancak $ Docker görüntüleri çalıştırırsanız, bulabilirsiniz Nginx Images Varsayılan (ilk denememizde çalıştığımız) ve benim-WordPress görüntüsümüz.Boyutuna bakın: Varsayılan görüntüler ~ 182MB, özel resmimiz sadece ~ 61MB’dir.Alpine sürümünü kullanmak için ilk komutu (DockerFile kullanmadan önce) çalıştırabileceğimizi düşünebilirsiniz ve gerçekten de yapabiliriz, bu örneği seçiminiz hakkında biraz araştırma yaparak görüntü boyutunuzu nasıl azaltabileceğinizi göstermek için kullanıyorum.Nginx durumunda, çok şey var.
Aynı komutu bir parametre olmadan çalıştırmaya çalışırsanız ($ Docker Run -p 8080: 80 My -wordPress) index.html’imizi artık sunucu olarak görmeyeceksiniz -Welcome sayfası varsayılan nginx, bu çok yararlı değil , DockerFile’a (altta) başka talimatlar ekleyelim: dizin.html/usr/nginx/html’yi kopyalayın. aynı ad). Bir kez daha, büyük bir sorun değil, ama sadece imajımızı yeterince yapıyoruz. Dağıtılabilir. Hacim kullanma ve dosyaları kopyalama arasındaki temel fark, genellikle hacmini geliştirmeye yüklemeniz, ancak dağıtım için görüntülere (üretim) kopyalanan dosyaları gerektirmesidir. Hacmi geliştirmeye yüklemek çok zaman kazandırır, çünkü her değişiklik için görüntüleri yeniden inşa etmenize gerek yoktur – Docker, yerel olarak sahip olduğunuz şeyle görüntüde geçici olarak değiştirilen kaynak dizini. Bu neden şaşırtıcı? Geliştirme makinemize hiçbir şey yüklememiz gerekmediğinden, koşmak istediğimiz her şeyi çalıştırmak için gereken her şey resim tarafından sağlanıyor! Bu, artık geliştirme bilgisayarınıza Nginx, PHP veya MySQL yüklemenize gerek olmadığı anlamına gelir, bu iyi bir şeydir, tüm bu süreçler kapatmazsak değerli kaynaklar gerektirir – ve çoğu değil, sadece içeri girerler. arkaplan. Yani daha fazla resim yaparsanız ve hacim koymadan çalıştırırsanız, Hello World’i göreceksiniz!
Yeniden. Nginx nginx resimlerini yapılandırarak artık aktif ve çalışıyoruz, ancak orada yeterli değiliz – bunu ihtiyaçlarımıza göre değiştirmemiz gerekiyor. Elbette en önemli kısmı sanal ev sahibi. Bunu yapmak için varsayılan yapılandırmayı değiştirmemiz gerekir. Nerede olduğunu öğrenmek için kabı bağlayalım: $ Docker Run -wit -wordpress /bin /sh SSH’yi önceki sunucuya bağlamak için kullandıysanız, bu komut çok benzer görünebilir, ancak aslında hiçbir SSH dahil değildir Burada, yalnızca varsayılan konteyner kabuğunu çalıştırırız ve komut satırımıza (veya OSX kullanıyorsanız terminale) ekliyoruz -kısım -onu etkileşimli hale getirir. Genellikle Debian/Ubuntu tabanlı sistemde, nginx yapılandırması/nginx/nginx olarak ayarlanır ve neyse ki bu görüntü aynı yapıyı kullanır, bu nedenle $ ls -al /etc/gnx/conf.d/ çalıştırırsanız ( kapsayıcı), yakında temizleyeceğimiz varsayılan.conf adlı bir dosya göreceksiniz. Ama önce, orada sanal bir ev sahibi olduğunu araştıralım: $ cat /etc/nginx/conf.d/default.conf
Çıktıdaki sunucu bloğuna {…} dikkat edin?İşte burada.Şimdi bu dosyanın kendi sürümünü oluşturalım: Konteynerden bağlantıyı kesmek ve Nginx.conf adlı proje dizinimizde yeni bir dosya oluşturmak için $ çıkışını çalıştıralım.Aşağıdaki snippet’leri içine yerleştirin: Sunucu {Server_name _;Dinle 80 Varsayılan_server;Kök/var/www/html;index.php index.html;Access_log /dev /stdout;error_log /dev /stdout bilgi;Konum / {try_files $ uri $ uri / /index.php?ored;} Konum ~ .php $ {fastcgi_params dahil;Fastcgi_pass my-php: 9000;fastcgi_index index.php;fastcgi_param script_filename $ document_root $ fastcgi_script_name;}} İndex.php henüz mevcut olmadığından, proje dizininde index.html’nin yanında yapın ve
içinde.Sonra DockerFile’ı açın ve şu şekilde değiştirin: Nginx’ten: 1.9 -alpine koruyucu Tomaz Age Run mkdir -p/var/www/html workdir/var/www/html kopya nginx.conf /etc/nginx/conf.d/ Varsayılan. Confop kopya../ nginx’ten: 1.9 -Alpine koruyucu Tomaz Run mkdir -p/var/www/html workdir/var/www/html kopya nginx.conf/etc/nginx/conf.d/default.conf kopya../ Buraya bazı talimatlar ekledik: Kopyala (zaten bildiğimiz), Run ve Workdir.Şimdilik son ikisini görmezden gelebiliriz, ancak görüntü oluşturmada önemli bir kavram sunarlar: Her proje bir kök dizini gerektirir ve varsayılan en iyisi (veya orada değil) değildir, bu yüzden önce/var/www/ HTML (WordPress kurulumumuzun kökü olacak) ve daha sonra WorkDIR’ı üzerinde ayarlayın, yani tüm sonraki talimatların kullanabileceği anlamına gelir./ Geçerli çalışma dizini tanımlamak için.Örnekler bu dockerfile’ın son satırında:
Kopyalıyoruz. /var/www/html/resimde ana bilgisayar proje dizininizdeki tüm dosyaları üretecektir. Workdir temel olarak Linux’ta CD komutunu çalıştırmakla aynı şeyi yapar. Bir görüntü yapmaya ve çalıştırmaya çalışırsanız, bir hata alırsınız, çünkü varsayılan olarak Nginx görüntüleri yalnızca eski HTML’yi sunar. Bununla birlikte, yapılandırmamızda, henüz mevcut olmayan başka bir resme (MY-PHP) atıfta bulunan FastCGI bloğunu (konum ~ .php $ {…}) tanıtıyoruz, şimdi yapalım. PHP-FPM görüntüleri Nginx ve php-fpm’yi aynı kapta çalıştırmaya çalışan bir Docker görüntüsü gördüm, bu benim için büyük bir yasak. Yukarıda bahsettiğimiz tek sorumluluk ilkesini hatırlıyor musunuz? Sahip olmamız gereken iki resim: biri Nginx (porsiyon sorumluluk olduğu yer) ve diğeri PHP-FPM (PHP ayrıştırma sorumluluğudur) için. Neden önemli iki ayrı görüntünüz var? Hemen göreceğiniz gibi, kaptaki işlem arka planda çalışmaz (veya en azından en azından olması gerekmez), işlem ana kap işlemesi olarak çalışmalıdır ve sadece başarısız olursa, Docker (veya yönetici yazılımı) bir şeylerin olacağını bilecek ve en azından kabı yeniden başlatmaya çalışacaktır. Yani ideal olarak, bir resim =>
Bir ön arka plan işlemi. Gerçekten de, Nginx yerine Apache çalıştırırsak, bu sorun mevcut olmayacaktır (PHP bir Apache modülü olarak mevcuttur, bu nedenle ayrı bir işlem yoktur), ancak bazen bu, öğrenme amacıyla birçok şeyi karmaşıklaştırmak için yararlıdır. Buna ek olarak, birçok gelişmiş geliştirici çeşitli nedenlerle Apache üzerinden Nginx’i tercih ediyor – ve ben de. PHP resmimizi oluşturmak için önce resmi depodaki seçeneklerimizi araştıralım. Birçoğu var, ama kimse MySQL ve diğer birçok WordPress bağımlılıkına doğuştan destek almıyor, bu yüzden bir kez daha kendimizi yapmaya zorlanıyoruz. Ama bu bir sorun olmamalı çünkü Dockerfile’da sadece birkaç satır, değil mi? Hadi bunu yapalım; DockerFile.php-fpm adlı yeni bir DockerFile oluşturun ve PHP’den aşağıdaki kodu girin: PHP’den: 7.0.6-fpm-alpin koruyucu Tomaz Age Run Docker-Php-Ext-Install -J $ (GREP -C ^Processor /Proc /Cpuinfo 2>/dev/null || 1) iconv gd mbstring dosya curl xmlreader xmlwriter spl ftp mysqli hacim/var/www/html php: 7.0.6-fpm-alpin-ext-ext-ext-ext-ext-ext korumak -Sostall $ (grep -c ^işlemci /proc /cpuinfo 2>
/Dev/null || 1) iconv gd mbstring filefo curl xmlreader xmlwriter spl ftp mysqli hacim/var/www/html çalışma talimatları burada biraz farklıdır çünkü varsayılan olarak resmi görüntüde olmayan ve wordpress çalıştırmak için ihtiyacımız olan bazı bağımlılıklar yüklemeliyiz. Neyse ki, sahip olduğumuz bir Docker-PHP-Ext-install komutumuz var (nereden geldiğini anlamıyorsanız Docker Hub’daki belgeyi okuyun) ve buna -J parametresi diyoruz. Bu komut ilk başta oldukça korkutucu görünüyor, ancak aslında sadece kaç işlemcinin kullanılabileceğini uzatma kurulumunu anlatmak için. Bu önemlidir, çünkü bazı PHP uzantılarının hızlı bir şekilde derlenmesi gerekir – pahalı bilgi işlem işlemleri. Şimdi bir php-fpm görüntü oluşturalım: $ Docker Build -t My-php-file dockerfile.php-fpm. Ekranda (derleme) birçok şeyin olduğunu göreceksiniz, ancak uzun sürmeyecek. Ve neyse ki bizim için, Docker, katman olarak adlandırılan talimatları depolar – bu serinin bir sonraki bölümünde daha fazla bilgi, bu yüzden aynı komutu tekrar çalıştırmaya çalışırsanız, sadece bir saniye sürecektir. Dockerfile’ın son biti bir cilt talimatıdır. Bu sefer, dosyayı ilk başta biraz kafa karıştırıcı görünebilecek resme kopyalamadık, bu yüzden ne olduğunu açıklayayım: Görüntünün kendi kaynak dosyası yok, harici bir cildin içine yüklenmesini bekleyin. Çalışma zamanı ve burada Docker’ın diğer faydaları yatıyor:
Konteynerler arasında hacimleri paylaşabiliriz, yani birkaç keyfi ana bilgisayar dizini aynı anda bir dizi kapa bağlayabiliriz ve hepsinin oraya erişeceği. Bu önemlidir, çünkü Nginx ve PHP-FPM’deki dosyalar arasında tutarsızlıklara neden olacak ve bundan kaçınmak istiyoruz. Öyleyse neden aralarında aynı verileri paylaşmıyorsunuz? Her iki resim ile hazırız, aralarındaki sürücü sürücüsünü test etmenin zamanı geldi. İlk olarak, PHP -FPM görüntülerini görüntüleyin (çünkü bu Nginx yapılandırmamıza bağımlılıktır) ve arka planda çalıştırılır (olan -d anlamına gelir): $ Docker Run -v $ (PWD):/var/www/html -name -name My-php -d my-php, bu komut hiçbir şey döndürmediğinden, konteynerin çalıştığından emin olmak için $ Docker PS’yi çalıştırın. Konteyner kimliğini kaydedin, çünkü $ Docker Stop F0B621891979 girerek durdurmanız gerekir (son dizeyi kimliğinizle değiştirin). Ve gerçekten de çalışır: ayrıca, ona bir isim verdiğimizi unutmayın, böylece bunu şöyle gösterdiğimiz Nginx görüntüsüne bağlayabiliriz: $ Docker Run -it-Link My-Php: My-php -p 8080: 80 WordPress’im tarayıcıya geri dönün ve Nginx’in çalıştığını doğrulamak ve bak!
Buradan bir sonraki mantıklı adım, MySQL imajımızı kurmaktır, ancak yapmadan önce hayatımızı biraz daha kolaylaştıracak diğer araçları ziyaret edelim; Şimdi fark edebileceğiniz gibi, Docker komutu çok uzun soluklu olabilir ve her zamanki gibi, bunun için ~~ bir uygulama ~~ araç var! Komutlar Yapmaya devam etmeden önce, bir görüntü oluşturmak ve kabımızı çalıştırmak için çalıştırmamız gereken bazı komutları kontrol edelim. Daha da önemlisi, hangi parçaları tekrar tekrar araştıralım: Her iki görüntünün/var/www/html altında yüklenmesini gerektiren her iki görüntü gerektirir
Her iki görüntü de belirli bağlantı noktalarını ortaya çıkarır (Nginx için 80, PHP-FPM için 9000)
Her iki görüntü de özel dockerfile’dan yapılmıştır
Nginx, PHP-FPM’ye güveniyor.
Hayatımızı kolaylaştırmak için Docker, komutu daha kısa (ve daha az) hale getirmek için tüm bu yapılandırmayı dosyalara koymamızı sağlayan bir araçla gönderilir. Bu araca Docker-Compose (eski adıyla bir incir olarak adlandırılır) olarak adlandırılır ve proje dizininizde olmak için Docker-Compose.yml adlı bir dosya gerektirir, bu yüzden bir tane oluşturun ve bu kodu girin: ‘2’ Hizmetler : My-nginx: yapı :. Birimler: – DockerFile: DockerFile.php -fpm Ciltler: -.:/var/www/html bağlantı noktaları: -“9000: 9000”
Her zaman görüntüleme ve adlandırılan görüntüleri hızlı bir şekilde işaretlemek yerine Docker, yapılandırma dosyasından gereken tüm bilgileri çıkarın. İçinde iki hizmet tanımlıyoruz, biri Myginx (Nginx görüntüümüz) ve diğeri My-Php olarak adlandırılıyor. My-nginx görüntüleri, oluşturma yolu için geçerli dizini kullanır (bu nedenle) çünkü Docker-Compose varsayılan olarak DockerFile’ı bekliyor. Ayrıca, ana bilgisayardaki mevcut proje dizinini bir kapta/var/www/html’ye (hacim kilidi kilidi aracılığıyla) yerleştirdik ve ayrıca artık ihtiyaç duyulmayacak komutlarımız gibi bağlantı noktalarını da eşleştiriyoruz. Son olarak, onu perde arkasında bir dahili ağ oluşturarak PHP-docker görüntüsüne bağladık. My-Php görüntüsü için, oluşturma anahtarı biraz farklıdır, çünkü DockerFile standart adı kullanmaz (daha fazla ayrıntı için buraya bakın). Myginx görüntüsümüz gibi, hacim koyup bağlantı noktasını da haritalıyoruz. Şimdi bu eğlenceli bir bölüm! Bir bağlantı noktası işçisi kompozisyonu kullanarak görüntüler yapmak için sadece çalıştırın (önbellekleme etkisini görmek için iki kez yapın): $ docker-compose yapılar yapıldıktan sonra, konteyneri açmak için sadece bir komut daha çalıştırmamız gerekiyor: $ Docker-compose haH ! Her şey bu-artık uzun liman işçileri siparişleri, tam dockerlar yok!
MySQL’e ne dersin? Tartışmadığımız bir Docker ile görüntü oluşturmanın çok önemli bir kısmı çevresel değişkendir. Öğreticimizin bir sonraki bölümünde biraz daha derin tartışacağız, ancak kısa bir giriş için MySQL görüntülerimizi kullanarak oluşturacağız. PHP-FPM görüntülerimizden farklı olarak, özel bir MySQL görüntüsü yapmaya gerek yok (isterseniz), resmi şey ihtiyacımız olan her şeyle gönderildi! Bu nedenle, uzun ve karmaşık Docker komutunu özleyeceğiz ve doğrudan Docker-Compose.yml dosyasına yapılandırma ekleyeceğiz. Aşağıdaki satırı altına ekleyin (diğer hizmetler gibi çıkıntılı olmamak için dikkatli olun): my-mysql: resim: mariadb: 5.5 cilt:-/var/lib/mysql ortam: wp mysql_database: wp mysql_user: wp mysql_sword Ayrıca onu benim-php görüntüsünden bağlamayı unutmayın, bu yüzden bunu sonunda ekleyin: My-php: (mevcut yapılandırma) Bağlantılar: -My-mysql $ Docker-compose derlemesini çalıştırmaya çalışırsanız, göreceksiniz MySQL görüntüsünün oluşturulmadığı -resmi bir depoda yapıldığı ve saklandığı için, sadece indirmemiz gerekiyor, bu da çalıştırdığınızda otomatik olarak gerçekleşecek, devam edin: $ Docker gerçekten emin olmak için. Works, kod düzenleyicinize geçin (ancak Docker-compose’u durdurmayın) ve projenizin kök dizininde db-testi.php adlı yeni bir dosya oluşturun ve aşağıdaki içeriği aşağıdakilere girin: <? Php $ dbuser = '' wp '; $ dbpass = 'wp'; $ dbhost = 'my-mysql'; $ connect = mysqli_connect ($ dbhost, $ dbuser, $ dbpass) veya die ("'$ dbhost'a bağlanılamıyor'
“); Echo” db’ye bağlı! “; Tarayıcınıza geri dönün ve bu dosyayı adres çubuğuna manuel olarak girin: http: // localhost: 8000/db-testi.php. Bağlı görüyorsanız DB!, İyi yapılmış iş için kendinize dokunun! Öyleyse neden çalışıyor? Mariadb’ın görüntüsü resmi olarak çevresel değişkenleri en yaygın yapılandırma seçeneği olarak kabul edecek şekilde yapıldığı için yapılır. Yapılandırma ve bu seçeneği orada ayarlayın. Yapılandırma seçenekleri olarak çevresel değişkenlere sahip olmak, uygulamalarımızı dağıtmaya başladıktan sonra (ve WordPress farklı değildir) (birçok sunucu aynı kodu sunar) – 12 uygulamaya uyuyor . Gösterilmesi gereken son kısım Volumes Düğmesidir. Burada, herhangi bir ana bilgisayar dizisine eşlemiyoruz, ancak sadece birimi belirleyin, evet Ng, perde arkasında (ve Docker tarafından bilinir) yapılacaktır. Bu yararlıdır, çünkü daha önce öğrendiğimiz gibi, görüntü değiştirilemez, bu nedenle yapmazsak, rezervuarı durdurduğumuzda tüm MySQL verileri kaybolacaktır. Bu şekilde, bu hacmi sürecimiz ve verilerimiz arasında sürekli hale getiriyoruz. Sonuç Bu öğreticide öğrendiklerimizi özetleyelim: DockerFile, özel Docker görüntüleri yapmak (veya daha ziyade mevcut olanı genişletmek için) bir plandır.
Docker görüntüsü tek kullanımlık bir dosya sistemidir, dağıtılabilir ve değiştirilemez
Docker kapsayıcıları, görüntülerin çalıştırılabileceği temel bir Linux ortamı sağlar
Her proje, Docker görüntüsünün kendisini bir Docker ile gereksinimlere göre belirleyebilir, yerel olarak hiçbir şey yüklememiz gerekmez (Docker’ın kendisi dışında)
Birçok amaç için, yalnızca Docker Hub’dan mevcut görüntüleri kullanabiliriz
Docker, boru hattında Windows ve Mac desteği ile Linux’a özgü çalışıyor
Her şey için görüntüler yapabiliriz, ancak her birinin genellikle ön arka planda çalışan süreçler şeklinde bir sorumluluğu olmalıdır
Docker-compose, bizi yazmayı kurtarmanın kolay bir yolunu sunar
Eşleme, ana bilgisayar kaynaklarını kapsayıcıya bağlamanın kolay bir yolunu sağlar
Kurulum, ana bilgisayar dizini kapsayıcıya bağlamanın kolay bir yolunu sağlar
Tüm bunların ilk başta çok korkutucu olabileceğini fark ettim, ancak Docker’ın sadece bu öğretici boyunca açıklanan birçok fayda nedeniyle değil, aynı zamanda bir şey yapmaya zorlayacağı için geleceğe bir yol olduğuna inanıyorum. Yöntemin iyi mi kötü mü olduğuna karar veriyorsunuz, ancak bunu geliştiricilerin çoğunluğunu gelecek için güçlü bir temel haline getiriyor. Ancak WordPress bize bunu öğretti. WordPress’ten bahsetmişken, bu bölümde tartışmıyoruz çünkü yeterince uzun oldu ve emmek için zamana ihtiyaç duyacak, bu yüzden önümüzdeki haftalarda planlanan bir sonraki yazıda tartışacağım. Abone olduğunuzdan emin olun!
Bu makalenin teknik incelemesi için Mario Peshev’e teşekkür etmek istiyorum.
Bu öğreticide tartışmayacağımız, ancak bahsetmeye değer bir DockerFile talimatı CMD talimatıdır.Talimat, konteyner herhangi bir parametre olmadan başladığında çalıştırılacak varsayılan komutu ayarlar, ancak Nginx DockerFile bunu yaptı çünkü tanımlamamız gerekmez.Değilse, Nginx’i böyle komutlarla çalıştırmalıyız (örneğin, çalıştırmaya gerek yok): $ docker run -v $ (pwd):/usr/share/nginx/html -p 8080: 80 nginx nginx – G “Daemon Off;”(Nginx kelimesinin neden iki kez göründüğünü merak ediyorsanız: ilk örnek görüntünün adıdır, ikincisi -ve öyle -kapta çalıştırdığımız gerçek komuttur) Görüntümüzü oluşturmak için: $ Docker -t -wordpress oluştur.
Bu komut, geçerli dizinde DockerFile’ı okur ve görüntüyü benim-WordPress’e etiketler, çünkü yazması, işaretlemezsek Docker tarafından üretilen bir dizi rastgele karakterden daha kolaydır.Test etmek için, çalıştır: $ Docker Run -v $ (pwd):/usr/share/nginx/html -p 8080: 80 benim -wordpress çok fazla değişiklik değil, ancak $ Docker görüntüleri çalıştırırsanız, bulabilirsiniz Nginx Images Varsayılan (ilk denememizde çalıştığımız) ve benim-WordPress görüntüsümüz.Boyutuna bakın: Varsayılan görüntüler ~ 182MB, özel resmimiz sadece ~ 61MB’dir.Alpine sürümünü kullanmak için ilk komutu (DockerFile kullanmadan önce) çalıştırabileceğimizi düşünebilirsiniz ve gerçekten de yapabiliriz, bu örneği seçiminiz hakkında biraz araştırma yaparak görüntü boyutunuzu nasıl azaltabileceğinizi göstermek için kullanıyorum.Nginx durumunda, çok şey var.
Aynı komutu bir parametre olmadan çalıştırmaya çalışırsanız ($ Docker Run -p 8080: 80 My -wordPress) index.html’imizi artık sunucu olarak görmeyeceksiniz -Welcome sayfası varsayılan nginx, bu çok yararlı değil , DockerFile’a (altta) başka talimatlar ekleyelim: dizin.html/usr/nginx/html’yi kopyalayın. aynı ad). Bir kez daha, büyük bir sorun değil, ama sadece imajımızı yeterince yapıyoruz. Dağıtılabilir. Hacim kullanma ve dosyaları kopyalama arasındaki temel fark, genellikle hacmini geliştirmeye yüklemeniz, ancak dağıtım için görüntülere (üretim) kopyalanan dosyaları gerektirmesidir. Hacmi geliştirmeye yüklemek çok zaman kazandırır, çünkü her değişiklik için görüntüleri yeniden inşa etmenize gerek yoktur – Docker, yerel olarak sahip olduğunuz şeyle görüntüde geçici olarak değiştirilen kaynak dizini. Bu neden şaşırtıcı? Geliştirme makinemize hiçbir şey yüklememiz gerekmediğinden, koşmak istediğimiz her şeyi çalıştırmak için gereken her şey resim tarafından sağlanıyor! Bu, artık geliştirme bilgisayarınıza Nginx, PHP veya MySQL yüklemenize gerek olmadığı anlamına gelir, bu iyi bir şeydir, tüm bu süreçler kapatmazsak değerli kaynaklar gerektirir – ve çoğu değil, sadece içeri girerler. arkaplan. Yani daha fazla resim yaparsanız ve hacim koymadan çalıştırırsanız, Hello World’i göreceksiniz!
Yeniden. Nginx nginx resimlerini yapılandırarak artık aktif ve çalışıyoruz, ancak orada yeterli değiliz – bunu ihtiyaçlarımıza göre değiştirmemiz gerekiyor. Elbette en önemli kısmı sanal ev sahibi. Bunu yapmak için varsayılan yapılandırmayı değiştirmemiz gerekir. Nerede olduğunu öğrenmek için kabı bağlayalım: $ Docker Run -wit -wordpress /bin /sh SSH’yi önceki sunucuya bağlamak için kullandıysanız, bu komut çok benzer görünebilir, ancak aslında hiçbir SSH dahil değildir Burada, yalnızca varsayılan konteyner kabuğunu çalıştırırız ve komut satırımıza (veya OSX kullanıyorsanız terminale) ekliyoruz -kısım -onu etkileşimli hale getirir. Genellikle Debian/Ubuntu tabanlı sistemde, nginx yapılandırması/nginx/nginx olarak ayarlanır ve neyse ki bu görüntü aynı yapıyı kullanır, bu nedenle $ ls -al /etc/gnx/conf.d/ çalıştırırsanız ( kapsayıcı), yakında temizleyeceğimiz varsayılan.conf adlı bir dosya göreceksiniz. Ama önce, orada sanal bir ev sahibi olduğunu araştıralım: $ cat /etc/nginx/conf.d/default.conf
Çıktıdaki sunucu bloğuna {…} dikkat edin?İşte burada.Şimdi bu dosyanın kendi sürümünü oluşturalım: Konteynerden bağlantıyı kesmek ve Nginx.conf adlı proje dizinimizde yeni bir dosya oluşturmak için $ çıkışını çalıştıralım.Aşağıdaki snippet’leri içine yerleştirin: Sunucu {Server_name _;Dinle 80 Varsayılan_server;Kök/var/www/html;index.php index.html;Access_log /dev /stdout;error_log /dev /stdout bilgi;Konum / {try_files $ uri $ uri / /index.php?ored;} Konum ~ .php $ {fastcgi_params dahil;Fastcgi_pass my-php: 9000;fastcgi_index index.php;fastcgi_param script_filename $ document_root $ fastcgi_script_name;}} İndex.php henüz mevcut olmadığından, proje dizininde index.html’nin yanında yapın ve
Bu komut, geçerli dizinde DockerFile’ı okur ve görüntüyü benim-WordPress’e etiketler, çünkü yazması, işaretlemezsek Docker tarafından üretilen bir dizi rastgele karakterden daha kolaydır.Test etmek için, çalıştır: $ Docker Run -v $ (pwd):/usr/share/nginx/html -p 8080: 80 benim -wordpress çok fazla değişiklik değil, ancak $ Docker görüntüleri çalıştırırsanız, bulabilirsiniz Nginx Images Varsayılan (ilk denememizde çalıştığımız) ve benim-WordPress görüntüsümüz.Boyutuna bakın: Varsayılan görüntüler ~ 182MB, özel resmimiz sadece ~ 61MB’dir.Alpine sürümünü kullanmak için ilk komutu (DockerFile kullanmadan önce) çalıştırabileceğimizi düşünebilirsiniz ve gerçekten de yapabiliriz, bu örneği seçiminiz hakkında biraz araştırma yaparak görüntü boyutunuzu nasıl azaltabileceğinizi göstermek için kullanıyorum.Nginx durumunda, çok şey var.
Aynı komutu bir parametre olmadan çalıştırmaya çalışırsanız ($ Docker Run -p 8080: 80 My -wordPress) index.html’imizi artık sunucu olarak görmeyeceksiniz -Welcome sayfası varsayılan nginx, bu çok yararlı değil , DockerFile’a (altta) başka talimatlar ekleyelim: dizin.html/usr/nginx/html’yi kopyalayın. aynı ad). Bir kez daha, büyük bir sorun değil, ama sadece imajımızı yeterince yapıyoruz. Dağıtılabilir. Hacim kullanma ve dosyaları kopyalama arasındaki temel fark, genellikle hacmini geliştirmeye yüklemeniz, ancak dağıtım için görüntülere (üretim) kopyalanan dosyaları gerektirmesidir. Hacmi geliştirmeye yüklemek çok zaman kazandırır, çünkü her değişiklik için görüntüleri yeniden inşa etmenize gerek yoktur – Docker, yerel olarak sahip olduğunuz şeyle görüntüde geçici olarak değiştirilen kaynak dizini. Bu neden şaşırtıcı? Geliştirme makinemize hiçbir şey yüklememiz gerekmediğinden, koşmak istediğimiz her şeyi çalıştırmak için gereken her şey resim tarafından sağlanıyor! Bu, artık geliştirme bilgisayarınıza Nginx, PHP veya MySQL yüklemenize gerek olmadığı anlamına gelir, bu iyi bir şeydir, tüm bu süreçler kapatmazsak değerli kaynaklar gerektirir – ve çoğu değil, sadece içeri girerler. arkaplan. Yani daha fazla resim yaparsanız ve hacim koymadan çalıştırırsanız, Hello World’i göreceksiniz!
Yeniden. Nginx nginx resimlerini yapılandırarak artık aktif ve çalışıyoruz, ancak orada yeterli değiliz – bunu ihtiyaçlarımıza göre değiştirmemiz gerekiyor. Elbette en önemli kısmı sanal ev sahibi. Bunu yapmak için varsayılan yapılandırmayı değiştirmemiz gerekir. Nerede olduğunu öğrenmek için kabı bağlayalım: $ Docker Run -wit -wordpress /bin /sh SSH’yi önceki sunucuya bağlamak için kullandıysanız, bu komut çok benzer görünebilir, ancak aslında hiçbir SSH dahil değildir Burada, yalnızca varsayılan konteyner kabuğunu çalıştırırız ve komut satırımıza (veya OSX kullanıyorsanız terminale) ekliyoruz -kısım -onu etkileşimli hale getirir. Genellikle Debian/Ubuntu tabanlı sistemde, nginx yapılandırması/nginx/nginx olarak ayarlanır ve neyse ki bu görüntü aynı yapıyı kullanır, bu nedenle $ ls -al /etc/gnx/conf.d/ çalıştırırsanız ( kapsayıcı), yakında temizleyeceğimiz varsayılan.conf adlı bir dosya göreceksiniz. Ama önce, orada sanal bir ev sahibi olduğunu araştıralım: $ cat /etc/nginx/conf.d/default.conf
Çıktıdaki sunucu bloğuna {…} dikkat edin?İşte burada.Şimdi bu dosyanın kendi sürümünü oluşturalım: Konteynerden bağlantıyı kesmek ve Nginx.conf adlı proje dizinimizde yeni bir dosya oluşturmak için $ çıkışını çalıştıralım.Aşağıdaki snippet’leri içine yerleştirin: Sunucu {Server_name _;Dinle 80 Varsayılan_server;Kök/var/www/html;index.php index.html;Access_log /dev /stdout;error_log /dev /stdout bilgi;Konum / {try_files $ uri $ uri / /index.php?ored;} Konum ~ .php $ {fastcgi_params dahil;Fastcgi_pass my-php: 9000;fastcgi_index index.php;fastcgi_param script_filename $ document_root $ fastcgi_script_name;}} İndex.php henüz mevcut olmadığından, proje dizininde index.html’nin yanında yapın ve
içinde.Sonra DockerFile’ı açın ve şu şekilde değiştirin: Nginx’ten: 1.9 -alpine koruyucu Tomaz Age Run mkdir -p/var/www/html workdir/var/www/html kopya nginx.conf /etc/nginx/conf.d/ Varsayılan. Confop kopya../ nginx’ten: 1.9 -Alpine koruyucu Tomaz Run mkdir -p/var/www/html workdir/var/www/html kopya nginx.conf/etc/nginx/conf.d/default.conf kopya../ Buraya bazı talimatlar ekledik: Kopyala (zaten bildiğimiz), Run ve Workdir.Şimdilik son ikisini görmezden gelebiliriz, ancak görüntü oluşturmada önemli bir kavram sunarlar: Her proje bir kök dizini gerektirir ve varsayılan en iyisi (veya orada değil) değildir, bu yüzden önce/var/www/ HTML (WordPress kurulumumuzun kökü olacak) ve daha sonra WorkDIR’ı üzerinde ayarlayın, yani tüm sonraki talimatların kullanabileceği anlamına gelir./ Geçerli çalışma dizini tanımlamak için.Örnekler bu dockerfile’ın son satırında:
Kopyalıyoruz. /var/www/html/resimde ana bilgisayar proje dizininizdeki tüm dosyaları üretecektir. Workdir temel olarak Linux’ta CD komutunu çalıştırmakla aynı şeyi yapar. Bir görüntü yapmaya ve çalıştırmaya çalışırsanız, bir hata alırsınız, çünkü varsayılan olarak Nginx görüntüleri yalnızca eski HTML’yi sunar. Bununla birlikte, yapılandırmamızda, henüz mevcut olmayan başka bir resme (MY-PHP) atıfta bulunan FastCGI bloğunu (konum ~ .php $ {…}) tanıtıyoruz, şimdi yapalım. PHP-FPM görüntüleri Nginx ve php-fpm’yi aynı kapta çalıştırmaya çalışan bir Docker görüntüsü gördüm, bu benim için büyük bir yasak. Yukarıda bahsettiğimiz tek sorumluluk ilkesini hatırlıyor musunuz? Sahip olmamız gereken iki resim: biri Nginx (porsiyon sorumluluk olduğu yer) ve diğeri PHP-FPM (PHP ayrıştırma sorumluluğudur) için. Neden önemli iki ayrı görüntünüz var? Hemen göreceğiniz gibi, kaptaki işlem arka planda çalışmaz (veya en azından en azından olması gerekmez), işlem ana kap işlemesi olarak çalışmalıdır ve sadece başarısız olursa, Docker (veya yönetici yazılımı) bir şeylerin olacağını bilecek ve en azından kabı yeniden başlatmaya çalışacaktır. Yani ideal olarak, bir resim =>
Bir ön arka plan işlemi. Gerçekten de, Nginx yerine Apache çalıştırırsak, bu sorun mevcut olmayacaktır (PHP bir Apache modülü olarak mevcuttur, bu nedenle ayrı bir işlem yoktur), ancak bazen bu, öğrenme amacıyla birçok şeyi karmaşıklaştırmak için yararlıdır. Buna ek olarak, birçok gelişmiş geliştirici çeşitli nedenlerle Apache üzerinden Nginx’i tercih ediyor – ve ben de. PHP resmimizi oluşturmak için önce resmi depodaki seçeneklerimizi araştıralım. Birçoğu var, ama kimse MySQL ve diğer birçok WordPress bağımlılıkına doğuştan destek almıyor, bu yüzden bir kez daha kendimizi yapmaya zorlanıyoruz. Ama bu bir sorun olmamalı çünkü Dockerfile’da sadece birkaç satır, değil mi? Hadi bunu yapalım; DockerFile.php-fpm adlı yeni bir DockerFile oluşturun ve PHP’den aşağıdaki kodu girin: PHP’den: 7.0.6-fpm-alpin koruyucu Tomaz Age Run Docker-Php-Ext-Install -J $ (GREP -C ^Processor /Proc /Cpuinfo 2>/dev/null || 1) iconv gd mbstring dosya curl xmlreader xmlwriter spl ftp mysqli hacim/var/www/html php: 7.0.6-fpm-alpin-ext-ext-ext-ext-ext-ext korumak -Sostall $ (grep -c ^işlemci /proc /cpuinfo 2>
/Dev/null || 1) iconv gd mbstring filefo curl xmlreader xmlwriter spl ftp mysqli hacim/var/www/html çalışma talimatları burada biraz farklıdır çünkü varsayılan olarak resmi görüntüde olmayan ve wordpress çalıştırmak için ihtiyacımız olan bazı bağımlılıklar yüklemeliyiz. Neyse ki, sahip olduğumuz bir Docker-PHP-Ext-install komutumuz var (nereden geldiğini anlamıyorsanız Docker Hub’daki belgeyi okuyun) ve buna -J parametresi diyoruz. Bu komut ilk başta oldukça korkutucu görünüyor, ancak aslında sadece kaç işlemcinin kullanılabileceğini uzatma kurulumunu anlatmak için. Bu önemlidir, çünkü bazı PHP uzantılarının hızlı bir şekilde derlenmesi gerekir – pahalı bilgi işlem işlemleri. Şimdi bir php-fpm görüntü oluşturalım: $ Docker Build -t My-php-file dockerfile.php-fpm. Ekranda (derleme) birçok şeyin olduğunu göreceksiniz, ancak uzun sürmeyecek. Ve neyse ki bizim için, Docker, katman olarak adlandırılan talimatları depolar – bu serinin bir sonraki bölümünde daha fazla bilgi, bu yüzden aynı komutu tekrar çalıştırmaya çalışırsanız, sadece bir saniye sürecektir. Dockerfile’ın son biti bir cilt talimatıdır. Bu sefer, dosyayı ilk başta biraz kafa karıştırıcı görünebilecek resme kopyalamadık, bu yüzden ne olduğunu açıklayayım: Görüntünün kendi kaynak dosyası yok, harici bir cildin içine yüklenmesini bekleyin. Çalışma zamanı ve burada Docker’ın diğer faydaları yatıyor:
/Dev/null || 1) iconv gd mbstring filefo curl xmlreader xmlwriter spl ftp mysqli hacim/var/www/html çalışma talimatları burada biraz farklıdır çünkü varsayılan olarak resmi görüntüde olmayan ve wordpress çalıştırmak için ihtiyacımız olan bazı bağımlılıklar yüklemeliyiz. Neyse ki, sahip olduğumuz bir Docker-PHP-Ext-install komutumuz var (nereden geldiğini anlamıyorsanız Docker Hub’daki belgeyi okuyun) ve buna -J parametresi diyoruz. Bu komut ilk başta oldukça korkutucu görünüyor, ancak aslında sadece kaç işlemcinin kullanılabileceğini uzatma kurulumunu anlatmak için. Bu önemlidir, çünkü bazı PHP uzantılarının hızlı bir şekilde derlenmesi gerekir – pahalı bilgi işlem işlemleri. Şimdi bir php-fpm görüntü oluşturalım: $ Docker Build -t My-php-file dockerfile.php-fpm. Ekranda (derleme) birçok şeyin olduğunu göreceksiniz, ancak uzun sürmeyecek. Ve neyse ki bizim için, Docker, katman olarak adlandırılan talimatları depolar – bu serinin bir sonraki bölümünde daha fazla bilgi, bu yüzden aynı komutu tekrar çalıştırmaya çalışırsanız, sadece bir saniye sürecektir. Dockerfile’ın son biti bir cilt talimatıdır. Bu sefer, dosyayı ilk başta biraz kafa karıştırıcı görünebilecek resme kopyalamadık, bu yüzden ne olduğunu açıklayayım: Görüntünün kendi kaynak dosyası yok, harici bir cildin içine yüklenmesini bekleyin. Çalışma zamanı ve burada Docker’ın diğer faydaları yatıyor:
Konteynerler arasında hacimleri paylaşabiliriz, yani birkaç keyfi ana bilgisayar dizini aynı anda bir dizi kapa bağlayabiliriz ve hepsinin oraya erişeceği. Bu önemlidir, çünkü Nginx ve PHP-FPM’deki dosyalar arasında tutarsızlıklara neden olacak ve bundan kaçınmak istiyoruz. Öyleyse neden aralarında aynı verileri paylaşmıyorsunuz? Her iki resim ile hazırız, aralarındaki sürücü sürücüsünü test etmenin zamanı geldi. İlk olarak, PHP -FPM görüntülerini görüntüleyin (çünkü bu Nginx yapılandırmamıza bağımlılıktır) ve arka planda çalıştırılır (olan -d anlamına gelir): $ Docker Run -v $ (PWD):/var/www/html -name -name My-php -d my-php, bu komut hiçbir şey döndürmediğinden, konteynerin çalıştığından emin olmak için $ Docker PS’yi çalıştırın. Konteyner kimliğini kaydedin, çünkü $ Docker Stop F0B621891979 girerek durdurmanız gerekir (son dizeyi kimliğinizle değiştirin). Ve gerçekten de çalışır: ayrıca, ona bir isim verdiğimizi unutmayın, böylece bunu şöyle gösterdiğimiz Nginx görüntüsüne bağlayabiliriz: $ Docker Run -it-Link My-Php: My-php -p 8080: 80 WordPress’im tarayıcıya geri dönün ve Nginx’in çalıştığını doğrulamak ve bak!
Buradan bir sonraki mantıklı adım, MySQL imajımızı kurmaktır, ancak yapmadan önce hayatımızı biraz daha kolaylaştıracak diğer araçları ziyaret edelim; Şimdi fark edebileceğiniz gibi, Docker komutu çok uzun soluklu olabilir ve her zamanki gibi, bunun için ~~ bir uygulama ~~ araç var! Komutlar Yapmaya devam etmeden önce, bir görüntü oluşturmak ve kabımızı çalıştırmak için çalıştırmamız gereken bazı komutları kontrol edelim. Daha da önemlisi, hangi parçaları tekrar tekrar araştıralım: Her iki görüntünün/var/www/html altında yüklenmesini gerektiren her iki görüntü gerektirir
Her iki görüntü de belirli bağlantı noktalarını ortaya çıkarır (Nginx için 80, PHP-FPM için 9000)
Her iki görüntü de özel dockerfile’dan yapılmıştır
Nginx, PHP-FPM’ye güveniyor.
Hayatımızı kolaylaştırmak için Docker, komutu daha kısa (ve daha az) hale getirmek için tüm bu yapılandırmayı dosyalara koymamızı sağlayan bir araçla gönderilir. Bu araca Docker-Compose (eski adıyla bir incir olarak adlandırılır) olarak adlandırılır ve proje dizininizde olmak için Docker-Compose.yml adlı bir dosya gerektirir, bu yüzden bir tane oluşturun ve bu kodu girin: ‘2’ Hizmetler : My-nginx: yapı :. Birimler: – DockerFile: DockerFile.php -fpm Ciltler: -.:/var/www/html bağlantı noktaları: -“9000: 9000”
Her zaman görüntüleme ve adlandırılan görüntüleri hızlı bir şekilde işaretlemek yerine Docker, yapılandırma dosyasından gereken tüm bilgileri çıkarın. İçinde iki hizmet tanımlıyoruz, biri Myginx (Nginx görüntüümüz) ve diğeri My-Php olarak adlandırılıyor. My-nginx görüntüleri, oluşturma yolu için geçerli dizini kullanır (bu nedenle) çünkü Docker-Compose varsayılan olarak DockerFile’ı bekliyor. Ayrıca, ana bilgisayardaki mevcut proje dizinini bir kapta/var/www/html’ye (hacim kilidi kilidi aracılığıyla) yerleştirdik ve ayrıca artık ihtiyaç duyulmayacak komutlarımız gibi bağlantı noktalarını da eşleştiriyoruz. Son olarak, onu perde arkasında bir dahili ağ oluşturarak PHP-docker görüntüsüne bağladık. My-Php görüntüsü için, oluşturma anahtarı biraz farklıdır, çünkü DockerFile standart adı kullanmaz (daha fazla ayrıntı için buraya bakın). Myginx görüntüsümüz gibi, hacim koyup bağlantı noktasını da haritalıyoruz. Şimdi bu eğlenceli bir bölüm! Bir bağlantı noktası işçisi kompozisyonu kullanarak görüntüler yapmak için sadece çalıştırın (önbellekleme etkisini görmek için iki kez yapın): $ docker-compose yapılar yapıldıktan sonra, konteyneri açmak için sadece bir komut daha çalıştırmamız gerekiyor: $ Docker-compose haH ! Her şey bu-artık uzun liman işçileri siparişleri, tam dockerlar yok!
Her iki görüntü de belirli bağlantı noktalarını ortaya çıkarır (Nginx için 80, PHP-FPM için 9000)
Her iki görüntü de özel dockerfile’dan yapılmıştır
Nginx, PHP-FPM’ye güveniyor.
Hayatımızı kolaylaştırmak için Docker, komutu daha kısa (ve daha az) hale getirmek için tüm bu yapılandırmayı dosyalara koymamızı sağlayan bir araçla gönderilir. Bu araca Docker-Compose (eski adıyla bir incir olarak adlandırılır) olarak adlandırılır ve proje dizininizde olmak için Docker-Compose.yml adlı bir dosya gerektirir, bu yüzden bir tane oluşturun ve bu kodu girin: ‘2’ Hizmetler : My-nginx: yapı :. Birimler: – DockerFile: DockerFile.php -fpm Ciltler: -.:/var/www/html bağlantı noktaları: -“9000: 9000”
Her zaman görüntüleme ve adlandırılan görüntüleri hızlı bir şekilde işaretlemek yerine Docker, yapılandırma dosyasından gereken tüm bilgileri çıkarın. İçinde iki hizmet tanımlıyoruz, biri Myginx (Nginx görüntüümüz) ve diğeri My-Php olarak adlandırılıyor. My-nginx görüntüleri, oluşturma yolu için geçerli dizini kullanır (bu nedenle) çünkü Docker-Compose varsayılan olarak DockerFile’ı bekliyor. Ayrıca, ana bilgisayardaki mevcut proje dizinini bir kapta/var/www/html’ye (hacim kilidi kilidi aracılığıyla) yerleştirdik ve ayrıca artık ihtiyaç duyulmayacak komutlarımız gibi bağlantı noktalarını da eşleştiriyoruz. Son olarak, onu perde arkasında bir dahili ağ oluşturarak PHP-docker görüntüsüne bağladık. My-Php görüntüsü için, oluşturma anahtarı biraz farklıdır, çünkü DockerFile standart adı kullanmaz (daha fazla ayrıntı için buraya bakın). Myginx görüntüsümüz gibi, hacim koyup bağlantı noktasını da haritalıyoruz. Şimdi bu eğlenceli bir bölüm! Bir bağlantı noktası işçisi kompozisyonu kullanarak görüntüler yapmak için sadece çalıştırın (önbellekleme etkisini görmek için iki kez yapın): $ docker-compose yapılar yapıldıktan sonra, konteyneri açmak için sadece bir komut daha çalıştırmamız gerekiyor: $ Docker-compose haH ! Her şey bu-artık uzun liman işçileri siparişleri, tam dockerlar yok!
MySQL’e ne dersin? Tartışmadığımız bir Docker ile görüntü oluşturmanın çok önemli bir kısmı çevresel değişkendir. Öğreticimizin bir sonraki bölümünde biraz daha derin tartışacağız, ancak kısa bir giriş için MySQL görüntülerimizi kullanarak oluşturacağız. PHP-FPM görüntülerimizden farklı olarak, özel bir MySQL görüntüsü yapmaya gerek yok (isterseniz), resmi şey ihtiyacımız olan her şeyle gönderildi! Bu nedenle, uzun ve karmaşık Docker komutunu özleyeceğiz ve doğrudan Docker-Compose.yml dosyasına yapılandırma ekleyeceğiz. Aşağıdaki satırı altına ekleyin (diğer hizmetler gibi çıkıntılı olmamak için dikkatli olun): my-mysql: resim: mariadb: 5.5 cilt:-/var/lib/mysql ortam: wp mysql_database: wp mysql_user: wp mysql_sword Ayrıca onu benim-php görüntüsünden bağlamayı unutmayın, bu yüzden bunu sonunda ekleyin: My-php: (mevcut yapılandırma) Bağlantılar: -My-mysql $ Docker-compose derlemesini çalıştırmaya çalışırsanız, göreceksiniz MySQL görüntüsünün oluşturulmadığı -resmi bir depoda yapıldığı ve saklandığı için, sadece indirmemiz gerekiyor, bu da çalıştırdığınızda otomatik olarak gerçekleşecek, devam edin: $ Docker gerçekten emin olmak için. Works, kod düzenleyicinize geçin (ancak Docker-compose’u durdurmayın) ve projenizin kök dizininde db-testi.php adlı yeni bir dosya oluşturun ve aşağıdaki içeriği aşağıdakilere girin: <? Php $ dbuser = '' wp '; $ dbpass = 'wp'; $ dbhost = 'my-mysql'; $ connect = mysqli_connect ($ dbhost, $ dbuser, $ dbpass) veya die ("'$ dbhost'a bağlanılamıyor'
“); Echo” db’ye bağlı! “; Tarayıcınıza geri dönün ve bu dosyayı adres çubuğuna manuel olarak girin: http: // localhost: 8000/db-testi.php. Bağlı görüyorsanız DB!, İyi yapılmış iş için kendinize dokunun! Öyleyse neden çalışıyor? Mariadb’ın görüntüsü resmi olarak çevresel değişkenleri en yaygın yapılandırma seçeneği olarak kabul edecek şekilde yapıldığı için yapılır. Yapılandırma ve bu seçeneği orada ayarlayın. Yapılandırma seçenekleri olarak çevresel değişkenlere sahip olmak, uygulamalarımızı dağıtmaya başladıktan sonra (ve WordPress farklı değildir) (birçok sunucu aynı kodu sunar) – 12 uygulamaya uyuyor . Gösterilmesi gereken son kısım Volumes Düğmesidir. Burada, herhangi bir ana bilgisayar dizisine eşlemiyoruz, ancak sadece birimi belirleyin, evet Ng, perde arkasında (ve Docker tarafından bilinir) yapılacaktır. Bu yararlıdır, çünkü daha önce öğrendiğimiz gibi, görüntü değiştirilemez, bu nedenle yapmazsak, rezervuarı durdurduğumuzda tüm MySQL verileri kaybolacaktır. Bu şekilde, bu hacmi sürecimiz ve verilerimiz arasında sürekli hale getiriyoruz. Sonuç Bu öğreticide öğrendiklerimizi özetleyelim: DockerFile, özel Docker görüntüleri yapmak (veya daha ziyade mevcut olanı genişletmek için) bir plandır.
Docker görüntüsü tek kullanımlık bir dosya sistemidir, dağıtılabilir ve değiştirilemez
Docker kapsayıcıları, görüntülerin çalıştırılabileceği temel bir Linux ortamı sağlar
Her proje, Docker görüntüsünün kendisini bir Docker ile gereksinimlere göre belirleyebilir, yerel olarak hiçbir şey yüklememiz gerekmez (Docker’ın kendisi dışında)
Birçok amaç için, yalnızca Docker Hub’dan mevcut görüntüleri kullanabiliriz
Docker, boru hattında Windows ve Mac desteği ile Linux’a özgü çalışıyor
Her şey için görüntüler yapabiliriz, ancak her birinin genellikle ön arka planda çalışan süreçler şeklinde bir sorumluluğu olmalıdır
Docker-compose, bizi yazmayı kurtarmanın kolay bir yolunu sunar
Eşleme, ana bilgisayar kaynaklarını kapsayıcıya bağlamanın kolay bir yolunu sağlar
Kurulum, ana bilgisayar dizini kapsayıcıya bağlamanın kolay bir yolunu sağlar
Tüm bunların ilk başta çok korkutucu olabileceğini fark ettim, ancak Docker’ın sadece bu öğretici boyunca açıklanan birçok fayda nedeniyle değil, aynı zamanda bir şey yapmaya zorlayacağı için geleceğe bir yol olduğuna inanıyorum. Yöntemin iyi mi kötü mü olduğuna karar veriyorsunuz, ancak bunu geliştiricilerin çoğunluğunu gelecek için güçlü bir temel haline getiriyor. Ancak WordPress bize bunu öğretti. WordPress’ten bahsetmişken, bu bölümde tartışmıyoruz çünkü yeterince uzun oldu ve emmek için zamana ihtiyaç duyacak, bu yüzden önümüzdeki haftalarda planlanan bir sonraki yazıda tartışacağım. Abone olduğunuzdan emin olun!
Bu makalenin teknik incelemesi için Mario Peshev’e teşekkür etmek istiyorum.
Docker görüntüsü tek kullanımlık bir dosya sistemidir, dağıtılabilir ve değiştirilemez
Docker kapsayıcıları, görüntülerin çalıştırılabileceği temel bir Linux ortamı sağlar
Her proje, Docker görüntüsünün kendisini bir Docker ile gereksinimlere göre belirleyebilir, yerel olarak hiçbir şey yüklememiz gerekmez (Docker’ın kendisi dışında)
Birçok amaç için, yalnızca Docker Hub’dan mevcut görüntüleri kullanabiliriz
Docker, boru hattında Windows ve Mac desteği ile Linux’a özgü çalışıyor
Her şey için görüntüler yapabiliriz, ancak her birinin genellikle ön arka planda çalışan süreçler şeklinde bir sorumluluğu olmalıdır
Docker-compose, bizi yazmayı kurtarmanın kolay bir yolunu sunar
Eşleme, ana bilgisayar kaynaklarını kapsayıcıya bağlamanın kolay bir yolunu sağlar
Kurulum, ana bilgisayar dizini kapsayıcıya bağlamanın kolay bir yolunu sağlar
Tüm bunların ilk başta çok korkutucu olabileceğini fark ettim, ancak Docker’ın sadece bu öğretici boyunca açıklanan birçok fayda nedeniyle değil, aynı zamanda bir şey yapmaya zorlayacağı için geleceğe bir yol olduğuna inanıyorum. Yöntemin iyi mi kötü mü olduğuna karar veriyorsunuz, ancak bunu geliştiricilerin çoğunluğunu gelecek için güçlü bir temel haline getiriyor. Ancak WordPress bize bunu öğretti. WordPress’ten bahsetmişken, bu bölümde tartışmıyoruz çünkü yeterince uzun oldu ve emmek için zamana ihtiyaç duyacak, bu yüzden önümüzdeki haftalarda planlanan bir sonraki yazıda tartışacağım. Abone olduğunuzdan emin olun!
Bu makalenin teknik incelemesi için Mario Peshev’e teşekkür etmek istiyorum.
