Başlangıçta bu kursu okuyan, yıllık 900.000 yuan maaşı olan bir mimar
Zhihu'nun bir zamanlar sıcak bir liste sorusu vardı: "Çin'deki programcıların sayısı doymuş mu yoksa fazla mı?"
Onlardan biri, Gao Zan, "küçükler artıyor ve yaşlılar kıtlık içinde" diye yanıt verdi.
İşler değerlidir. BOSS'un "mimar bulut yerel" aramasında ilk üç, aylık maaşı 30.000 olan iki bahisçi var ve en yüksek aylık maaşı 60.000 ve bunlardan biri 14 maaş. Biri 15 maaş.
Sadece kıskanç maaşı hatırlamayın. Şu etiket dizisini gördünüz mü: "Dağıtılmış" DevOps "" Kapsayıcı Bulutu "...
Elbette, elmas olmadan porselen işi olmazdı.
Başkalarının ellerinin zenginliğini görmeyin, başkalarının terini de görmezden gelin.
Bir programcı olarak bilgi ve gelir her zaman orantılıdır. Bir mimar olmanıza ve mümkün olan en kısa sürede sevgilinizi kazanmanıza izin vermek için, 1 Nisan'da JD Cloud ve AI Bulut Ürün Geliştirme Departmanı'nın mimarı Jing Liangliang, Cloud Native altında DevOps: Cloud Native'in Altı Haftası hakkında bir konferans verdi. Ve sürekli teslimat, hadi bunun özünü gözden geçirelim!
Konsept ve giriş
Bulut yerel hakkında pek çok açıklama vardır. Bu PPT, kabaca bulut yerelinin sürekli teslimat + DevOps + mikro hizmetler + konteynerleştirme olduğu anlamına gelen iki yaygın ifadeyi listeler.
Başka bir deyişle, bulut yerel, yalnızca mikro hizmetleri, kapsayıcıları değil, aynı zamanda sürekli teslim, DevOps ve yeniden düzenleme gibi daha fazla yönetim yöntemini de içeren bir kavramlar koleksiyonudur.
Peki, bulut yerelini nasıl tanımlıyorsunuz? Aşağıdaki resim, CNCF resmi web sitesinin yerel bulut tanımıdır ve aynı zamanda nispeten güvenilir bir tanımdır. Bulut yerelini anlamak istiyorsanız, önce K8S'yi anlamalısınız çünkü bu, bulut yerelinin temel taşıdır.
K8S
K8S, CNCF'nin ilk projesidir ve bulut yerel ekosisteminin tamamı K8S üzerine inşa edilmiştir. Temsili bulut yerel teknolojileri arasında kapsayıcılar, mikro hizmetler, hizmet ızgaraları, değişmez altyapı ve bildirime dayalı API'ler bulunur.
DevOps
İnsanlar DevOps hakkında ne zaman konuşsa, bunu her zaman kör ve fil ile karşılaştırırlar. Birçok şirket buna farklı bir ad verir. Bazı şirketler, dahili çevrimiçi platformu kendilerinin oluşturduğu DevOps olarak tanımlayacaktır.
Ama önce Wikipedia'nın tanımına bakalım: yani, yazılım oluşturma, test etme ve yayınlamayı daha hızlı, daha sık ve güvenilir hale getirmek için "yazılım teslimi" ve "değişiklik inşa etme" sürecini otomatikleştirerek.
Sürekli entegrasyon, sürekli teslimat ve sürekli dağıtım
Sürekli teslimat, yazılım teslimatını daha hızlı ve daha sık hale getirebilir, yani herhangi bir zamanda piyasaya sürülebilir. Amacı, yazılım oluşturma, test etme ve daha hızlı ve daha sık yayınlamayı sağlamaktır. Verimliliği sağlamak için yalnızca daha hızlı teslimat yapabilirsiniz, ancak daha hızlı teslimatın temeli kaliteyi sağlamaktır. Sürekli teslimattan bahsetmişken, birçok kişi sürekli entegrasyon ve sürekli dağıtımdan da haberdar. Aşağıdaki şekilde gösterildiği gibi, üçü arasında belirli farklılıklar vardır.
Geleneksel yazılım geliştirmede, geliştiricilerin proje bittikten sonra entegrasyon yapması gerekir ve bu süreç birkaç haftadan birkaç aya kadar sürebilir. Yazılım geliştirmenin orta ve erken aşamalarında sık entegrasyon gerekir.Sık entegrasyonun avantajı, problemlerin keşfedilmesini son bağlantıya kadar engellemesidir.
Birçok kişi ekibimizin zaten entegre olduğunu söyleyebilir, peki bunu ne sıklıkla inşa ediyorsunuz? Oluşturma süreci her sürümden geçiyor mu? Öyleyse, sürekli entegrasyonu düşünün. Çünkü sürekli entegrasyon, sürekli teslimatın ilk adımıdır.
Sürekli teslimat, müşterilere sunmak için önceki tüm şeyleri bir araya getirmektir. Tabii ki, farklı şirketler bu aşamayı farklı, bazıları "test-üretim", bazıları "test-yarı üretim" veya "çevrimiçi" vb. Olarak adlandırılıyor.
Sürekli dağıtım, tüm bağlantıların otomatik olduğu anlamına gelir.Geliştirici kodu gönderdikten sonra, üretim ortamına otomatik olarak dağıtılabilir. Sürekli dağıtım ve sürekli teslimat arasındaki tek fark, geliştiricilerin ürünleri üretim ortamına otomatik olarak yayınlayıp yayınlayamayacağıdır.
Son yıllarda teknik terimler çok hızlı bir şekilde güncellendi. Bununla ilgili olarak, altyapı açısından en açık olanıdır.Bir uygulama birkaç yıl önce konuşlandırılmak üzere piyasaya sürüldüğünde, genellikle aşağıdaki seçenekler vardı: En iyi ve en temel yol bir bilgisayar odası inşa etmektir, ancak tüm donanım, ağ, su ve elektrik sorunları Bunu dikkate alın; ikinci olarak, sunucular oluşturun, işletim sistemlerini kurun ve son olarak dağıtın veya sanallaştırın.
Daha sonra VMware'e benzer bir sanal makine yapacağız, yani üzerinde dağıtım yöntemini sanallaştıracağız ve doğrudan bazı betikler yazıp çalıştırmak için çalıştıracağız. Daha sonra herkes OpenStack gibi özel bulut teknolojileriyle ilgilenmeye başladı.
Yöntem nasıl değişirse değişsin ve hangi altyapıyı kullanırsanız kullanın, sonunda bir hibrit bulut veya çoklu bulut yaklaşımına dönüşecektir.Teslimatınız yalnızca bu modelleri değil, aynı zamanda konteyner paketlerini de desteklemelidir. Şu anda, bu süreç giderek daha otomatik hale geliyor ve giderek daha fazla kişi iş taleplerini karşılayabilir. Örneğin, iş ihtiyaçlarını ve maliyet taleplerini karşılamak için esnek ölçeklendirme teknolojisini kullanacağız.
Sürekli Teslimat-Boru Hattı
Sürekli teslimat bir dizi süreç gerektirir.Bu tür ortamlarda, ister test, ister ön sürüm veya üretim olsun, müşterinin ortamına o kadar yakın olur. Her aşamadaki endişeler farklı olsa da, her işlemin ve ortamın doğrulama için serbest bırakılması gerektiğini göreceksiniz.
Ve ardışık düzen yoluyla, bu süreçler dizisi iyi bir şekilde otomatikleştirilebilir ve geliştiricilerin yapım verimliliği ve sürüm kalitesi de iyileştirilecektir.
Yazılım dağıtımının zorlukları ve sorunları
Yukarıdaki resim, 2019'daki bir DevOps anket raporunun ekran görüntüsüdür. Herkesin bildiği gibi, yazılım teslim sürecinin kendisi çevrimiçi değişiklikler anlamına gelir ve değişiklikler risk anlamına gelir. Teslimattaki en büyük zorluk, çevrimiçi işlem sırasında başarısızlıktır. Bunu yapmamak kesinlikle çevrimiçi arızalara neden olacaktır.
2019 anket raporu, ekiplerin% 81'inin başarısızlık oranını% 15 içinde kontrol edebildiğini, ancak% 5 içinde başarısızlık oranını kontrol edebilen ekiplerin yalnızca% 35'inin kontrol edebileceğini gösteriyor. Bu, 100 sürümde 50 arıza olduğu anlamına gelir. Bu nedenle, yazılım tesliminin kalitesi için değişiklikler çok önemlidir.
Kalite çok önemli olduğuna göre, teslimat aracı nasıl seçilir? Aşağıdaki resim referans amaçlıdır.
montaj hattı
Dünyanın ilk montaj hattı Ford Motor tarafından önerildi ve piyasaya sürüldü. O sırada, montaj hattı otomobil üretim verimliliğini büyük ölçüde artırdı. Geliştirici kodu gönderdikten ve yazılımı müşteriye teslim ettikten sonra bir dizi işlemden geçecektir. Peki bu süreç nasıl modellenir ve çalıştırılır?
Şu anda ilerlemek için montaj hattının hedeflerini birleştirmeliyiz.Montaj hattının amacı hızlı entegrasyon ve hızlı teslimattır.Montaj hattının aslında bir boru hattı olduğu söylenebilir.Standart bir prosesi yoktur, işletmeye göre özelleştirebiliriz.
Örneğin, bir ardışık düzen oluşturmak istediğinizde, kod tarama, kod testi, test dağıtımı ve yayın öncesi gibi bir dizi işleme ihtiyacınız olabilir. Ama yaptığınız montaj hattının iyi çalışmasını nasıl sağlayacaksınız?
Bu sorun zor değil, sadece aşağıdaki üç noktayı yapın.
İlk olarak otomatik inşaat yapılmalıdır. Birçok geliştirici, zaten otomasyon ve sürekli entegrasyon yaptıklarını düşünüyor. Ancak otomasyonu yeterince inşa etmiyorsanız ve yeterince zamanında değilseniz, o zaman test veya entegrasyon yoktur.
İkinci olarak, otomatik test yapılmalıdır. Yapımdan sonra üretilen ürün, ister işlevsel bir test, ister performans testi veya bir stres testi olsun test edilmelidir. Bu test süreci, beklenen kaliteye ulaşmak içindir, ancak duruma göre otomatikleştirilmelidir, çünkü yalnızca otomasyon verimliliği artırabilir.
Üçüncüsü, sürekli entegrasyon. Yalnızca boru hattı tekrar tekrar, hızlı ve sık çalıştığında sorunlar keşfedilebilir ve çözülebilir.
Tüm yazılım endüstrisinde, sürekli teslimat hedefine ulaşmak için en azından yukarıdaki üç noktaya ulaşılabilir.
En temel dağıtım boru hattı
Yukarıdaki resim en temel montaj hattı olsa da, kaynak kodu bağlantısı, gönderim bağlantı yapısı, test ve kod analizi vb. Dahil olmak üzere tüm bağlantıyı kapsadığını görebilirsiniz. Bundan sonra kabul, UAT testi üretim ortamı, ürünün üretime sunulması. çevre.
Bazı boru hattı uygulamaları
Yukarıdaki şekil, üç boyuta ayrılabilecek bazı boru hattı uygulamalarını göstermektedir:
İkili paket yalnızca bir kez oluşturulur
İkili paket yalnızca bir kez oluşturulur; bu, geliştiricinin bir ikili paket oluşturmak için her seferinde kodu yazdıktan sonra yeniden oluşturduğu ve ardından aşağıdaki işleme devam ettiği anlamına gelir. Bu sadece zaman israfını önlemekle kalmaz, aynı zamanda verimliliği de artırır.
Ancak öyle olsa bile, iki yapının sonuçları hala farklıdır çünkü kodunuz ve kimliğiniz değişmemiş olsa da paketiniz değişmiş olabilir.
Farklı ortamlarda aynı dağıtım yöntemini kullanın
Yayınlarken ve devreye alırken, test ortamına dağıtırken sürekli entegrasyon için Jenkins kullanmak yerine ve üretim ortamı piyasaya sürülmek üzereyken başka bir araç seti kullanmak yerine, test, yayın öncesi ve üretim gibi tüm dağıtım yöntemleri ve ortamları aynı şekilde dağıtılır. Dağıtmak için. Farklı dağıtım araçları, farklı nihai teslim edilen ürünlere yol açabilir.
Çevrimiçi üretim ortamında, ister fiziksel bir makine, ister bir bulut ana bilgisayarı veya sanallaştırılmış bir fiziksel makine kullanın, yüksek kullanılabilirlik performansını sağlamalısınız. Şu anda, çevrimiçi kullanıcıların erişilebilirliğini sağlamak için bir yığın kaynağa ihtiyaç vardır.
Boru hattı esnek olmalıdır
İşlem hattının önemi, verimliliği artırmak ve kaliteyi sağlamaktır, ancak geliştiricinin işi Java veya Go'ya sahip olabilir. Bu nedenle montaj hattınızın çeşitli talepleri karşılaması gerekir.
Örneğin, bazı ekipler için bir test ortamı seti yeterliyken, başka bir proje, projenin ortak hata ayıklama için diğer ekiplere sunulması gerektiğini düşünebilir.Şu anda, iki test ortamı, ortam A oluşturmak gibi test ortamının istikrarını sağlamak gerekir. Ekip, bunu proje doğrulaması için kullanabilir ve B ortamı, ortak hata ayıklama için üçüncü bir tarafa sağlanabilir.
Yapılması gereken son şey, tüm boru hattının inişini doğrulamaktır, tüm boru hattını inşa ettiğiniz ve sonra bu şekilde ilerlediğiniz söylenemez. Gerçekte iniş yaparken, her kod gönderimi tamamlandıktan sonra testi otomatik olarak tetikleme sürecinin tamamlanıp tamamlanmadığını dikkate almak gerekir.
Sürekli Teslimatta JD Zhilian Cloud Uygulaması
Her şirketin sürekli teslimat deneyimi adım adım ortaya çıkar.
JD.com'un en erken sabit lansman tarihi Salı ve Perşembe'dir. Kararlılığı sağlamak için, Ar-Ge personeli çevrimiçi ortamı çalıştıramaz, bu nedenle işletim ve bakım için çevrimiçi olmaları gerekir. Şu anda, ürün yöneticileri operasyon ve bakımın arkasında sıraya girecekler, ancak kuyruğa alma verimliliği nispeten düşüktür ve o sırada hiçbir çevrimiçi araç yoktur, otomasyon yetenekleri özellikle zayıftır ve çevrimiçi arızaların onarımı garanti edilemez. Daha sonra doldurmanın yollarını bulmaya başladım.
İki teslimat süreci
JD.com'un iki erken teslim süreci arasında, ilk teslimat süreci geliştirme, derleme ve oluşturma, kod analizi ve lansmanın tamamı için dış kaynak kullanımını kapsar.
Araçlar açısından, Artifactory'nin ticari versiyonu özel kullanım için, Jenkins kullanılıyor, kod taraması için SonarQube, nesne depolaması için dahili özel bulut ve yayıncılık için rsync kullanılıyor.
İkinci teslimat sürecinde, en büyük değişiklik rsync'i ANSIBLE ile değiştirmemiz oldu, bu gerçekten verimliliği büyük ölçüde artırdı ve kuyruk sorununu çözdü.
Bu nedenle, yayınlama sürecinde başlangıçta paket modunu kullandık, ancak daha sonra tam paket moduna değiştirdik. Diğer kısmı test ediyor. Başlangıçta sadece fonksiyonel testler yaptık. Daha sonra güvenlik testleri de yaptık. Statik kod taraması olduğu ortaya çıktı. Daha sonra güvenlik açıklarını da taradık. İki boru hattının ortak bir sorunu vardır, yani her boru hattının bir test paketi ve bir üretim paketi olacaktır.
JD Zhilian Cloud'un mevcut uygulaması temelde üç grup ortama bölünmüştür: bir test seti, bir başlangıç öncesi seti ve bir üretim seti. Test, lansman öncesi, üretim ve ağ birbirinden izole edilmiştir.
Yukarıdaki şekilde gösterildiği gibi, JD Zhilian Cloudun ardışık düzeni kaynak koddan, derlemeden, kod incelemesinden ve sırayla testten devam edecektir. Ön yayın bağlantısı ve üretim bağlantısı temelde ele alınmıştır. Temel işlev otomasyonu başarısız olursa geliştirici dağıtımı sağlamalıdır. Test ortamına ulaşıldıktan sonra, en azından test ortamının temel işlevlerinde herhangi bir sorun olmadığından emin olmak için test ortamının işlevleri otomatik olarak doğrulanabilir.
Tasarım açısından, tüm boru hattının kendisi bir boru hattıdır ve boru hattındaki her atomun işlevleri bağımsızdır.Örneğin, güvenlik kodu tespiti güvenlik ekibi için daha profesyonel olmalıdır. JD Zhilian Cloud, bu alanda yapılacak güvenlik ekibidir. Atomik kapasite oluşumunu sağlamak için bir güvenlik mekanizması sağlamak için, bunu boru hattından devralırız.
Sürekli teslimatın özü şartnamedir
Sürekli teslimatın bir düzenleme olduğu söylenebilir .. Herkes Jenkins'in özellikle popüler olduğunu bilir, öyleyse neden Jenkins doğrudan JD Zhilian Cloud'un sürekli dağıtımında kullanılamıyor? Çünkü sürekli teslimatın temel parçası şartnamedir. Platformun konuşlandırılması çayırda koyun gütmek gibidir.Çoban köpekleri sürüyü yönetmelidir.
JD Zhilian Cloud nasıl standartlaştırılır
JD Zhilian Cloud'un tüm çevrimiçi işlemleri aynı çevrimiçi platform kontrol sistemi ile yapılır.Bunun avantajı ilk olarak riskleri azaltmaktır ve birleşik kontrol sistemi saniyeler içinde geri dönebilir.
İkinci olarak, dağıtım platformunun yayınlamak için birleşik bir hesap kullanması gerekir ve bir problemden sonra çalıştırılması kolaydır. Birleştirilmiş ve standartlaştırılmış örnek dağıtım yolu ve günlük yolu, belirli bir dizine göre yapılır. Dizinde bir sorun varsa, sorunu günlük platformu veya JD Zhilian Cloud'un dahili platformu aracılığıyla hızlı bir şekilde bulabilirsiniz.
Ek olarak, JD Zhilian Cloud, tüm yönleri kapsayan eksiksiz bir DevOps platform setine sahiptir. Amaç, geliştiricilerin araçlar aracılığıyla daha iyi çalışabilmeleri için geliştirme, test etme, çalıştırma ve bakım dahil olmak üzere yazılım yaşam döngüsünün sorunlarını çözmektir. Tüm araç seviyesi proje işbirliğini, geliştirme araçlarını ve testleri içerir.
Yapılandırma yönetimi açısından, JD Zhilian Cloud'un yapılandırma yönetimi, personel rolü izinleri gibi yalnızca uygulama düzeyindeki bazı hizmet yönetimini kapsamaz. Bunlar temel verilerin çekirdeği olarak alındığında, izleme, yayınlama ve günlük kaydı gibi tüm temel hizmet verilerini içeren iş mantığı zaten mevcuttur.
JD Zhilian Cloud, Uygulamanın boyutlarına dayanır. Yukarı doğru, tüm organizasyon yapısıdır ve aşağı doğru, tüm modülün ve makinenin bilgilerini yönetir. Şu anda, makinenin serbest bırakılmasını düşünmeniz gerekmez. Yalnızca hangi Uygulamayı yayınlayacağınızı ve hangi trafiği değiştireceğinizi düşünmeniz gerekir. Yayınlamanın yolu. Sürekli teslimatın gerçek özü, bağlantı hatlarının tamamından geçmektir.JD Zhilian Cloud'un izlenmesi, yalnızca teknik izleme, altta yatan altyapı, konteynerler ve fiziksel makineleri içeren, aynı zamanda hibrit bulutları da destekleyen nispeten tam bağlantılı bir izlemedir.
Mevcut işletmelerin yalnızca bir tür bulutu kullanması veya yalnızca kendi özel bulutunu kullanması genellikle imkansızdır ve genel bulut yalnızca birini kullanmakla kalmayabilir, A ve B olabilir. Bu modelde, ister teslimat olsun Veya izleme, altyapı hibrit bulut modelini desteklemeliyiz. Bu durumda, birleşik zamanlama üst düzeyde sağlanmalı ve tüm izleme ve dağıtım aracıları da birleşik yönetim ve kontrol olmalıdır. Ek olarak, aşağıdaki şekilde gösterildiği gibi, JD Zhilian Cloud da bu konudaki kendi deneyimini ihraç edecek.
Plan nasıl yapılır
DevOps'u bir kuruluşta uygulamak için, durumun büyük bir kısmı, işletmenin halihazırda bir şeyler kullanması ve ardından bazı yetenekleri iyileştirmek için Jenkins'i kullanmak istemesidir. Şu anda neden değiştirmek istediğinizi düşünün ve patronunuzu veya iş arkadaşlarınızı dahili DevOps araç zincirinde değişiklik yapmaya ikna edin.
Bunu değiştirmenin iki yolu vardır: Biri, Ulusal Bilgi ve İletişim Teknolojileri Enstitüsü ve DevOps topluluğunun bir DevOps standardı yayınlamış olmasıdır. Bu standart yüzlerce uzman tarafından yazılmıştır.
Bulut yerel altında sürekli teslimat
JD Zhilian Cloud'da birçok araç zinciri var. Şu anda herkese açık bir test yapma sürecindeyiz. Gelecekte, dahili proje yönetimi uygulamasını yerel bir şekilde herkese açacağız.
Ops bölümü, kayıt hizmeti, izleme, bulutla arama, bulut olayları ve işletme ve bakımın temel makine yeteneklerini içerir. Bu aynı zamanda dahili olarak kendi geliştirdiğimiz "Kapı Tanrısı" adlı bir üründür. Bu ürün birkaç yıldır JD.com'u desteklemektedir. , 0 başarısızlık. Şu anda, JD Zhilian Cloud'un bulut tabanlı bir şekilde geliştirilmesinin bir sonraki adımda açık kaynaklı olması bekleniyor.
Ek olarak, JD Zhilian Cloud, geliştiricilerin hızla altyapı oluşturmasına yardımcı olabilecek Terraform ve Packer özelliklerini de destekler. JD Zhilian Cloud'un tamamı, çeşitli API'lere yerel bir şekilde araçlar sağlar. Amaç, herkesin yerel bulut altında kendi yeteneklerini oluşturmasına yardımcı olmaktır.
İpuçları
