Geliştirme ve Hazırlama Ortamlarında Büyük WordPress Medya Kitaplıklarını Kullanma Stratejileri

WP Offload S3 hakkında oldukça sık sorulan sorulardan biri, geliştirme veya hazırlama ortamlarında kullanmanın uygun olup olmadığıdır. Doğru yapıldığında, WP Boşaltma S3'ü kullanmak, yeni bir ortamı çoğaltmak için gereken süreyi ve bunun için gereken disk alanını büyük ölçüde azaltabilir. Yine de bu kedinin derisini yüzmenin birçok yolu var. Bunu yapmanın kanonik bir en iyi yolu olmasa da, tüm stratejileri gözden geçireceğiz ve artılarını ve eksilerini özetleyeceğiz. Dalalım, olur mu?

Sorun

Diyelim ki example.com canlı sitesi olan bir müşterimiz var. Şimdi müşteri, popüler sitelerinin tamamen yeniden tasarımı üzerinde çalışmaya başlamamızı istiyor. Bu yeni özellik üzerinde gizlice güvenle çalışabileceğimiz ayrı bir ortamın yanı sıra, müşterinin bize canlı yayına geçmemizi onaylamadan önce çalışmalarımızı gözden geçirebileceği bir yer kurmamız gerekiyor.

Müşterinin WordPress sitesini, WordPress çekirdeğini, temayı ve tüm eklentileri içeren staging.example.com alan adına sahip yeni bir sunucuya dağıtarak başlıyoruz. Ardından WP Migrate DB Pro kullanarak example.com veritabanını çekiyoruz. Ayrıca ortam kitaplığımızdaki tüm görüntülere hazırlık aşamasında da ihtiyacımız var, bu nedenle geçiş sırasında bunları kopyalamak için WP Migrate DB Pro için Medya Dosyaları Eklentisini kullanıyoruz. Müşterinin sitesinde 5.000'den fazla öğeden oluşan bir medya kitaplığı vardır, bu nedenle her şeyin kopyalanması uzun zaman alır.

Medya kitaplığı her iki ortamda da çoğaltılır ve ana bilgisayar sitesiyle aynı etki alanında sunulur.

Şimdi bu proje üzerinde çalışacak olan üç geliştiricinin, yerel geliştirme ortamlarını kurmak için bu süreci tekrarlamaları gerekiyor. O günün ilerleyen saatlerinde ekip nihayet çalışmaya hazır.

Bu, küçük siteler için kabul edilebilir, ancak iyi ölçeklenmiyor ve bunu sürdürmenin maliyeti medya kitaplığının boyutuyla orantılı olarak artıyor. Bu, özellikle ilk kez yeni bir ortam kurmaya gittiğinizde acı verir. Çok büyük bir medya kitaplığına sahip bir site için bunun indirilmesi saatler hatta günler alabilir.

Medya Kitaplığını Merkezileştirme

WP Boşaltma S3 kullanmanın faydalarından biri, her ortam için gereken disk alanı miktarını büyük ölçüde azaltmanıza izin vermesidir. Artık medya kitaplığını tekrar tekrar kopyalamak yerine, birden fazla ortamın paylaşabileceği yeni bir merkezi konuma taşındı.

WP Boşaltma S3, her medya kitaplığı öğesi için yüklenen URL'yi takip ettiğinden, her ortam bu varlıkları yerel olarak sahip olmadan paylaşabilir.
Kilidi Açılan Başarı: çok kısa sürede yeni ortamlar!

Paylaşılan Kaynakların Karanlık Yüzü

Hiç kardeşinle aynı odayı paylaştın mı? Birini tam klonunuzla paylaştığınızı hayal edin; sahip olduğun hiçbir şey güvende değil! Paylaşılan kaynakların faydaları kendi riskleriyle birlikte gelir, ancak onları anlayarak onlardan kaçınmak için iyi donanımlı olacağız.

Bizim durumumuzda, paylaşılan kaynak Amazon S3 kovasıdır. Bir S3 paketini paylaşmanın birincil riski, her ortamın potansiyel olarak paketin içeriğini karşıya yükleme, kaldırma veya başka bir şekilde değiştirme yeteneğine sahip olmasıdır. Genel olarak konuşursak, yalnızca üretim tarafından kullanılan varlıkların üretimden değiştirilmesini istersiniz.

WP Offload S3'ün önerilen ayarlarını kullanırken, Nesne Sürüm Oluşturma ayarı sayesinde bir dosyanın aynı adı taşıyan diğerinin üzerine yazılmasına karşı oldukça güvendesiniz.

Bu ayar, görüntünün boşaltıldığı zamana bağlı olarak S3'teki nesnenin yoluna bir zaman damgası ekler. Yerel olarak, dosyanızın şöyle bir yolu olabilir:

 wp-content/uploads/2017/03/sigourney-weaver.jpg

Nesne Sürüm Oluşturma etkinken (varsayılan olarak), S3 kovası içinde bu dosyanın şuna benzer bir yolu olur:

 wp-content/uploads/2017/03/22195347/sigourney-weaver.jpg

Bu, dosyaya benzersiz bir yol verir. Medya kitaplığı, aksi takdirde aynı dosya adına sahip olacak öğeleri numaralandırarak da çakışmaları önlemeye yardımcı olur. Nesne sürümü oluşturma olmadan, canlı siteye eklenen yeni bir öğenin ve başka bir ortamda aynı ada sahip başka bir öğenin önceki dosyanın üzerine yazarak kovadaki aynı yol için rekabet edebilmesi riski hala vardır. Nesne Sürümü Oluşturma, tarayıcıda ve CDN'de kullanmanız gereken önbellek geçersiz kılma sorununu çözerken bunu neredeyse imkansız hale getirir (medyanızı doğrudan S3 çocuklarından sunmayın).

“Dosyaları Sunucudan Kaldır”ı etkinleştirdiyseniz, WP Boşaltma S3, boşaltılan bir dosyanın S3'teki mevcut bir dosyanın üzerine yazmadığından emin olmak için ek kontroller gerçekleştirir.

Temizlemek

Geliştiriciler olarak, yeni özellikleri kapsamlı bir şekilde test ederken genellikle çok sayıda geçici veri ekliyoruz. S3'te depolama, fıstıkları paketlemek kadar ucuz olabilir, ancak ücretsiz değildir. Muhtemelen kovanıza bir sürü test çöpü atmak ve bunun için para ödemek istemezsiniz. Üretim dışı kullanım için bir kovaya yüklemek istiyorsak, kendimiz kolayca temizleyebilmek istiyoruz.

Kova içeriği ve ona erişim için biraz daha fazla dikkate alarak birkaç stratejiyi keşfedelim.

Paylaşılan Kova Stratejisi: Erişim Yok

İdeal olarak, üretim tarafından kullanılan hiçbir varlığı üretim dışı bir ortamdan kaldıramamalıyız. Bunu zorlamanın en kolay yolu, WP Offload S3'ün paketinize erişmesini engellemektir; bu, AWS eklentisinde ayarlanan erişim anahtarlarını kaldırmak kadar basittir. WP Boşaltma S3'ün, eklentinin ayarlar ekranı aracılığıyla yapılandırmadan önce erişim anahtarlarının ayarlanmasını gerektirdiğini unutmayın. S3'e erişime izin vermeden eklentinin ayarlarında değişiklik yapabilmek istiyorsanız, anahtarlarınızı sahte değerlerle değiştirebilirsiniz. Yeni medya kitaplığı öğeleri boşaltılmayacak ve mevcut öğeler S3 paketinizden veya özel etki alanınızdan sunulmaya devam ederken yerel sunucudan sunulacak.

Artıları

• Uygulaması en kolay
• Öğeler, üretim S3 paketine eklenemez veya buradan kaldırılamaz
• Mevcut boşaltılmış medya, paketten/CDN'den sunulmaya devam edilebilir
• Ek maliyet yok

Eksileri

• Yeni medya, üretimde olacağından farklı şekilde sunuluyor

Profesyonel İpucu — Eklenti ayarları ekranını kullanarak AWS erişim anahtarlarınızı değiştirmek, veritabanı canlı siteden tekrar çekilir çekilmez kaybolacaktır. Bu değişikliği kodunuzda programlı olarak zorlamak için ortama özel bir dosya kullanın! (Aşağıya bakınız)

Yeni varlıkların boşaltıldığını ve URL'lerin üretim dışı bir ortamda düzgün bir şekilde yeniden yazıldığını test etmenin gerekli olabileceği zamanlar olabilir. Bu durumda, farklı bir stratejiye ihtiyacımız var.

Paylaşılan Kova Stratejisi: Alternatif Yol

WP Boşaltma S3'ün Yol ayarı, S3 kovası içindeki yüklemeler (medya kitaplığı) kök dizinine giden temel yolu tanımlar. Varsayılan olarak, WordPress tarafından kullanılan yerel dosya sistemi yolunu yansıtır, ancak istediğiniz şekilde değiştirilebilir.

Bu yol, her medya kitaplığı öğesi için S3 nesne anahtarının bir parçası olarak kaydedildiğinden, URL'leri mevcut öğelere ayırmadan değiştirmekte özgürüz. Bu ayar değiştirildiğinde, etkilenen medya kitaplığı öğeleri yalnızca değişiklikten sonra eklenen öğelerdir.

Bu yaklaşımın yararı, diğer ortamlardan yapılan yüklemelerin, üretimden eklenenlerden kovada ayrı bir yolda yalıtılmasıdır. Testi tamamladığınızda, tüm geçici nesnelerinizi güvenli bir şekilde kaldırmak için S3 konsolunda oturum açabilir ve özel yolunuzu içeren dizini silebilirsiniz.

Hazırlama/geliştirme ortamlarınız için daha kısıtlayıcı bir ilkeyle oluşturulmuş farklı AWS IAM kimlik bilgilerini kullanmak da akıllıca olacaktır. Aşağıdaki politika, paketinizin özel yoluna yazma erişimini kısıtlar:

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:List*", "s3:getBucketLocation" ], "Resource": [ "arn:aws:s3:::BUCKET_NAME" ] }, { "Effect": "Allow", "Action": [ "s3:DeleteObject", "s3:Put*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::BUCKET_NAME/staging", "arn:aws:s3:::BUCKET_NAME/staging/*" ] } ] }

Artıları

• Yeni medya, tüm ortamlarda S3'ten boşaltılır ve sunulur
• Üretim dışı bir ortamdan eklenen ortam, kovada yalıtılmıştır ve daha sonra temizlenmesi kolaydır

Eksileri

• Alternatif IAM kimlik bilgilerinin kurulumu ve bakımı

Alternatif Kova Stratejisi

Yeni medya için WP Offload S3 tarafından kullanılacak yeni bir kova tanımlayarak kova ayarını da değiştirebiliriz. Yukarıdaki yolda gördüğümüz gibi, kova da her medya kitaplığı öğesine kaydedilir, böylece kova değişikliğinden yalnızca yeni medya etkilenir. Bu temelde aynı artıları ve eksileri olan yola dayalı stratejiyle aynı olduğundan, son stratejimize geçebiliriz.

Aynalı Kova Stratejisi

Burada, üretim tarafından kullanılan kovayı, üretim dışı ortamlarımızın paylaşması için yeni bir kovaya klonlayacağız. Bu, üretim tarafından kullanılan kovayı kirletme veya başka bir şekilde karıştırma riski olmadan üretim ortamını mümkün olduğunca yakın bir şekilde kopyalamak için en iyi seçenektir.

Yukarıda bahsedildiği gibi, kullanılan paket, her bir medya kitaplığı öğesi için veritabanında depolanır. WP Offload S3'ün yansıtılmış kovayı kullanmasını sağlamak için, eski kova adını yenisiyle değiştirmek için veritabanında bir arama ve değiştirme yapılmalıdır. Bu, geçiş sırasında WP Migrate DB Pro ile veya olaydan sonra WP-CLI ile yapılabilir. Bu, kova adına bağlı olarak başlı başına bir zorluk olabilir. Örneğin orijinal paket adı sitenizin alan adıyla aynıysa, paket adını değiştirmek için veritabanınızda bir arama ve değiştirme işlemi yaparken istenmeyen sonuçlara neden olabilir.

Kullanmak istediğimiz yeni kovayı oluşturduktan sonra, yine de üretim kovasındaki tüm nesneleri bu kovaya kopyalamamız gerekiyor. Kepçenizin ne kadar büyük olduğuna bağlı olarak, her şeyi yerel olarak indirir ve ardından yeni kepçeye yeniden yüklersek bu biraz zaman alabilir. İyi haber şu ki, doğrudan bir kovadan diğerine kopyalayabiliyoruz! Kötü haber şu ki, bu yazının yazıldığı sırada bunu S3 konsolundan yapamazsınız. Bir kovadan diğerine kopyalamanın en kolay yolu AWS CLI kullanmaktır.

Kurulduktan ve yapılandırıldıktan sonra, bir komut yeni kepçenizi tamamen dolduracaktır:

 aws s3 sync s3://your-production-bucket s3://your-staging-bucket

Bu komut, üretim kovasındaki tüm nesneleri henüz orada olmayan yeni kovaya kopyalayacaktır. Varsayılan olarak, hedefte kaynakta olmayan hiçbir nesneyi silmez (bunu etkinleştirmek için bir anahtar sağlayabilirsiniz), böylece gelecekte aynı komutu tekrar kullanmaya devam edebilirsiniz ve yalnızca eksik dosyaları ekler.

Artıları

• Tüm ortamlar, varlıklara üretimle aynı şekilde hizmet eder
• Tüm ortamlar, tüm nesneleri kovalarına ekleyebilir/kaldırabilir
• Daha sonra temizlemek, aynalı kovayı silmek kadar kolaydır

Eksileri

• Çoğu zaman alıcı ve potansiyel olarak kurulumu zor
• Yinelenen nesneler için ödeme

Ortam Tabanlı Konfigürasyon Oluşturma

Hazırlama/yerel veritabanınızı her yenilediğinizde ayarları UI aracılığıyla manuel olarak değiştirmek felaket için bir reçetedir. Örneğin, bir ödeme ağ geçidini korumalı alan moduna geçirmeyi unutmak ciddi sorunlara neden olabilir. IAM kimlik bilgilerini değiştirmeyi unutmak da olabilir. Çözüm, bu yapılandırmayı uygulama kodumuza dahil etmektir. Buradaki temel amaç, ortama özgü bir değeri zorlamak için seçilmiş birkaç ayar için veritabanını denklemden çıkarmaktır. Bunu yapmak için, tüm ortamlara dağıtılan uygulamaya fazladan PHP eklememiz gerekecek.

WP Boşaltma S3'ün tüm ayarları, sabitler aracılığıyla kontrol edilebilir. Bu sabitler içinde tanımlanan herhangi bir ayar, veritabanında depolananlara göre önceliklidir. Sadece sabitleri tanımladığımız için, bu kod wp-config.php wp-settings.php yüklenmeden önce herhangi bir yere eklenebilir.

Yine, bunu yapmanın birçok yolu vardır, bu yüzden işleri olabildiğince basit tutmaya çalışacağız. Daha kapsamlı bilgi için, Ayarlar Sabitleri için her zaman WP Boşaltma S3 belgelerine başvurabilirsiniz.

 <?php /** * DEFINE THE ENVIRONMENT CONSTANT 'WP_ENV' * There are many possible ways to set this, but it can only be defined once. * * Using an environment variable by the same name * define( 'WP_ENV', getenv( 'WP_ENV' ) ); * * Matching the hostname * define( 'WP_ENV', 'example.com' == $_SERVER['SERVER_NAME'] ? 'production' : 'staging' ); */ // These settings will take effect if the current environment is not production. if ( defined( 'WP_ENV' ) && WP_ENV != 'production' ) { /** * ALTERNATE/DUMMY CREDENTIALS * * Use alternate IAM credentials for limited permissions or use a placeholder * to prevent WP Offload S3 from being able to upload new objects, remove * existing objects, or read private objects. */ define( 'DBI_AWS_ACCESS_KEY_ID', 'ASDFASDFASDFASDFASDF' ); define( 'DBI_AWS_SECRET_ACCESS_KEY', 'ZXCVZXCVZXCVZXCVZXCVZXCVZXCVZXCVZXCVZXCV' ); /** * ALTERNATE BUCKET * Simply use a different bucket than is used in production. */ define( 'AS3CF_BUCKET', 'testing.example.com' ); /** * Override any of the Offload S3 settings. */ define( 'WPOS3_SETTINGS', serialize( array( // ALTERNATE PATH // Prefix the path in S3 with the current environment. 'object-prefix' => WP_ENV . '/wp-content/uploads/', ) ) ); }

Kapanış Düşünceleri

Amazon S3'ü kullanarak elde ettiğiniz tüm avantajlara ek olarak, WordPress medya kitaplığınızı S3'e boşaltmak, yeni ortamları daha hızlı ve daha kolay çalıştırmanızı sağlar. Her ortam için alternatif IAM kimlik bilgileri kullanarak üretim S3 klasörünüzdeki medyayı koruyabilir ve hatalardan kaçınmak için kodunuzda ortama özgü bu ayarları zorunlu kılabilirsiniz.

Offload S3'ü farklı ortamlarda kullanmak için hangi stratejiyi kullanıyorsunuz? WordPress'te ortam tabanlı yapılandırmayı çözmek için yaratıcı bir çözümünüz var mı? Eğer öyleyse, aşağıdaki yorumlarda bize her şeyi anlatın!