Kod perspektifi, DevOps'un derinlemesine anlaşılması | Güç Projesi
Yazar | Yitian Coder
Editör | Tang Xiaoyin
Ana resim | Dongfang IC'den indirin
Üretildi | CSDN Blogu
DevOps'un anlaşılması konusunda farklı görüşler var ve Wikipedia bile birleşik bir tanım vermedi. Genel açıklama, onu kelimenin tam anlamıyla almak, yani ürün lansmanından çevrimiçine kadar süreci hızlandırmak ve otomatikleştirmek için geliştirme ve operasyonları entegre etmektir. Bu, DevOps'un geniş bir yorumudur ve çoğu insan aynı fikirdedir. Ancak bu açıklama çok geniş, neredeyse tüm BT içeriğini de kapsıyor ve anlamsız kılıyor. DevOps yalnızca son yıllarda ortaya çıktı (ancak 2014'te popüler oldu) Belirli bir proje modelinin açıklamasıdır ve kendine özgü çağrışımları vardır. Herhangi bir proje iki bölüme ayrılabilir: geliştirme ve çalıştırma ve bakım ve DevOps'tan önce var olan ve değişmeyen bir dizi geliştirme süreci ve aracı.
DevOps'un gerçekten değiştiği şey, işletim ve bakımdır. Bu nedenle, DevOps'u operasyon ve bakım perspektifinden anlamak için özünü kavrayabilir miyiz? Bunu, dar bir anlayış olan operasyon ve bakım yapmak için geliştirmeyi kullanmak olarak anlayabilirsiniz (Geliştirme olarak Operasyon). Geliştirme yolu kod yazmaktır, diğer bir deyişle DevOps kod yazarak işlem ve bakım yapmaktır.
Operasyon ve bakımda çok popüler bir kavram, kod olarak "Iac (InfrastructureAsCode)" olarak adlandırılan altyapı, yani işletim ortamının oluşturulması kod şeklinde açıklanır ve kod çalıştırılarak ortam oluşturulur. Modern işletme ve bakım teknolojisi yaratan, işletim ve bakım alanında bir devrimdir ve aynı zamanda DevOps'un temel taşıdır. Ancak altyapı oluşturma, işletim ve bakımın yalnızca bir parçasıdır. Bu devrimi tüm operasyon ve bakım alanlarına genişletmeye devam edersek ve kodun tüm operasyon ve bakımı kapsamasına izin verirsek, o zaman olacaktır. Kod, Kod Olarak İşlemdir ve DevOps'un özü budur.
Öyleyse, bir uygulama projesi açısından DevOps nedir? Uygulama kodunu ve işletim ve bakım kodunu bir kaynak program kitaplığına koymak ve üzerinde sürüm yönetimini gerçekleştirmek, böylece proje hakkında tüm bilgilere sahip olursunuz ve programı dağıtabilirsiniz (programın kendisi ve Çalışma ortamı) ve her seferinde oluşturulan programın çalışan sonuçlarının aynı olmasını sağlayabilir (çünkü işletim ortamı da aynıdır).
Kod Olarak İşlem (Kod Olarak İşlem)
Operasyon ve bakımın yaptığı şeyleri tek tek inceleyelim ve kodda nasıl uygulandığına bakalım.
İşletme ve bakım çalışmaları genellikle aşağıdaki hususları içerir:
-
altyapı: Yani, program işletim ortamının oluşturulması ve sürdürülmesi.
-
Sürekli dağıtım: Uygulamayı dağıtın ve tüm süreci otomatikleştirin.
-
Hizmetin sağlamlığı: Bu, hizmetin işletim ortamında ağ arızası veya hizmetin aşırı yüklenmesi gibi bir sorun olduğunda veya bazı mikro hizmetler çalışmadığında, programın hizmetin bir kısmını veya çoğunu yine de sağlayabileceği anlamına gelir.
-
Operasyon izleme: Hem programın izlenmesini hem de işletim ortamının izlenmesini içerir.
Kod Olarak Altyapı (Kod Olarak Altyapı)
Altyapı oluşturmak için kodun nasıl kullanılacağını göstermek için örnek olarak bir Go (diğer diller de benzer) mikro hizmet programı kullanıyoruz. Programın kendi işlevi çok basittir, veritabanındaki verilere erişmek için SQL deyimlerini kullanın ve bunları günlüğe yazın. Bunu basitçe iki katmana ayırabilirsiniz, arka uç veri erişim katmanı ve veritabanı katmanı. Programın dağıtım ortamı, k8'lerin kapsayıcı ortamına bağlıdır. K8s'de iki servise bölünmüştür. Biri arka uç program hizmeti, diğeri ise veritabanı (MySQL kullanan) hizmetidir. Arka uç programının veritabanı hizmetini çağırması ve ardından günlüğe bazı verileri yazması gerekir.
Bu yeni modelde, işletim ortamının kodu ve uygulamanın kodu bir kaynak kod kitaplığında saklanır, böylece kaynak kod kitaplığını indirdiğinizde, yalnızca programın tüm kaynak koduna değil, aynı zamanda işletim ortamına da sahip olursunuz. Kaynak kodu. Bu şekilde, yeni bir çalışma zamanı ortamı oluşturulacağı zaman, kod bir kez çalıştırılarak tam bir çalışma zamanı ortamı oluşturulabilir ve her seferinde oluşturulan ortam tutarlıdır.
Yukarıdakiler Go programının dizin yapısıdır.İçinde işletim ortamıyla ilgili dosyaları özel olarak depolayan bir "komut dosyası" dizini vardır ve içindeki "kuburnetes" alt dizini tüm işletim ortamının kodudur. Uygulama kodu, "komut dosyası" dışındaki diğer dizinlerde saklanır. Bu şekilde bu uygulama ile ilgili bilgiler, kod şeklinde bir kaynak kod kitaplığında saklanır. Bununla birlikte, aynı programın çalışan bir ortamını istediğiniz zaman dağıtabilirsiniz ve tamamen aynı olması garanti edilir.
"Kubernetes" dizini altında arka uç programının ve veritabanının yapılandırma dosyalarını sırasıyla saklamak için iki alt dizin "arka uç" ve "veritabanı" vardır. İç yapıları benzerdir ve üç "yaml" dosyası vardır:
-
backend-deployment.yaml: dağıtım yapılandırma dosyası
-
backend-service.yaml: hizmet yapılandırma dosyası
-
backend-volume.yaml: kalıcı birim yapılandırma dosyası
Ek olarak, onun çalışan komutu olan bir ".sh" dosyası vardır Bu Kabuk dosyasını çalıştırdığınızda, bir çalışma ortamı oluşturmak için yukarıdaki üç k8s yapılandırma dosyasını çağırır.
Kubernetes dizininin en dış seviyesinde "k8sdemo-config.yaml" ve "k8sdemo-secret.yaml" olmak üzere iki "yaml" dosyası vardır.Farklı servisler tarafından paylaşıldıkları için k8s işletim ortamı parametreleri oluşturmak için kullanılırlar. En dıştaki katmana yerleştirin. Ayrıca k8s nesneleri oluşturmak için kullanılan bir k8s komut dosyası olan "k8sdemo.sh" dosyası da vardır.
Bu kaynak program yapısının bir avantajı, uygulamanın ve işletim ortamının daha iyi entegre edilebilmesidir. Örneğin, daha önce hizmet portunu değiştirmek istediğinizde, onu işletim ortamında ve kaynak kodunda ayrı ayrı değiştirmeniz gerekiyordu, ancak bu, geliştirme, çalıştırma ve bakım tarafından ayrı ayrı yapıldı ve bu, modifikasyonun kolayca senkronize olmamasına neden oldu. Bunları aynı kaynak kodu kitaplığına koyduğunuzda, yalnızca tek bir yeri değiştirmeniz gerekir, bu da uygulamanın ve işletim ortamının tutarlılığını sağlar.
Arka uç hizmeti için k8s yapılandırma kodu aşağıdadır:
apiVersion: v1 tür: Hizmet meta veriler: ad: k8sdemo-arka uç hizmeti etiketler: uygulama: k8sdemo-arka uç spec: tür: NodePort seçici: uygulama: k8sdemo-arka uç bağlantı noktaları: -protokol: TCP nodePort: 32080 bağlantı noktası: 80 targetPort: 8080Alan kısıtlamaları nedeniyle, program burada ayrıntılı olarak açıklanmayacaktır.Eğer ilgileniyorsanız, lütfen uygulamaları k8s'e nasıl taşıyacağınıza bakın.
Altyapı iki seviyeye ayrılabilir, biri yukarıda bahsedilen k8s seviyesi, yani uygulama ile yakından ilgili olan konteyner seviyesi. Bir diğer katman ise konteynerin altındaki destek katmanı yani sanal makine katmanıdır, tabii ki ağ ve yük dengeleme gibi ekipman veya yazılımları da içerir. Alibaba Cloud veya Huawei Cloud üzerinde k8'ler oluşturmadan önce bunları oluşturmalısınız. Dağıtımı kod ile de yapılabilir. Terraform, yaratımı tamamlamak için çok popüler bir araçtır.ThoughtWorks tarafından tavsiye edilir (ayrıntılar için ThoughtWorks TECHNOLOGY RADAR VOL.20'ye bakın) Sanal makineler oluşturmak için kod kullanımını destekler.
kod aşağıdaki gibi gösterilir:
kaynak "aws_instance" "örnek" { count = 10 ami = "ami-v1" instance_type = "t2.micro" }Ancak bu seviyede altyapının çalışması uygulama ile çok yakından ilgili değildir, bu nedenle kodun bu kısmı uygulamaya yerleştirilmez.Kodun bu kısmını depolamak için altyapı için ayrı bir kaynak kod projesi oluşturabilirsiniz.
Sürekli Dağıtım
Uygulamaları dağıtmak, işletim ve bakım için önemli bir görevdir. Ticari rekabetin yoğunlaşmasıyla birlikte, birkaç haftada bir orijinal dağıtımdan bir gün sonra bir düzine veya hatta düzinelerce dağıtıma kadar daha hızlı program güncellemeleri gerekir. Bu şekilde, manuel dağıtım ihtiyaçları hiç karşılayamaz, bu nedenle tüm sürecin otomatikleştirilmesi gerekir, bu da sürekli dağıtımdır.
Pipeline (Pipeline) çok önemli bir kavramdır, tüm adımları ve sürekli dağıtım sürecini tanımlamak için kullanılır. Jenkins çok popüler bir sürekli entegrasyon ve dağıtım aracıdır ve "Kod olarak ardışık düzen" önerir (ayrıntılar için Pipeline'a bakın). Sürekli dağıtım ardışık düzenini program kaynak kodunun bir parçası olarak ele almak ve onu uygulamayla birlikte yönetmek, böylece uygulama ile aynı sürüme ve gözden geçirme sürecine sahip olmaktır.
Aşağıda, nasıl elde edildiğini göstermek için belirli bir örnek kullanıyoruz. Bu örnek, yukarıdaki ile aynı programı kullanır. Önce programın dizin yapısına bakın.
Sürekli dağıtımla ilgili dosyaların tümü, iki kısma bölünmüş "script" dizinindedir; biri Jenkins işlem hattını depolayan "cd" alt dizini ve diğeri "Kubernetes" altındaki "jenkins" alt dizini. Jenkinsde'nin k8s yapılandırma dosyasını saklayın. Daha yakından bakarsanız, içindeki dosyaların daha önce bahsedilen arka uç programların ve veritabanlarının k8s yapılandırma dosyalarına çok benzediğini göreceksiniz.Bununla, k8s'de bir Jenkins çalışan ortamı oluşturabilirsiniz.
Burada Jenkins k8s konfigürasyon dosyasını uygulamaya koydum, ama aslında daha önce bahsedilen altyapı projesinin kaynak koduna koyulmalıdır. Çünkü Jenkins, tek bir uygulamaya ait olmaktan ziyade uygulamalar tarafından paylaşılıyor. Açıklama kolaylığı açısından burada bir araya getirilmişlerdir ve gerçekten kullanıldıklarında çıkarılmaları gerekir.
İşte boru hattının kodu:
def POD_LABEL = "k8sdemopod - $ {UUID.randomUUID.toString}" podTemplate (etiket: POD_LABEL, bulut: 'kubernetes', kapsayıcılar: , hacimler: ) { düğüm (POD_LABEL) { def kubBackendDirectory = "/ script / kubernetes / arka uç" stage ('Checkout') { container ('modifiye-jenkins') { sh'echo github'dan kaynak al ' git'https: //github.com/jfeng45/k8sdemo ' } } stage ('Build image') { def imageName = "jfeng45 / jenkins-k8sdemo: $ {env.BUILD_NUMBER}" def dockerDirectory = "$ {kubBackendDirectory} / docker / Dockerfile-k8sdemo-arka uç" container ('modifiye-jenkins') { withCredentials () { sh "" " docker girişi -u $ {DOCKER_HUB_USER} -p $ {DOCKER_HUB_PASSWORD} docker build -f $ {WORKSPACE} $ {dockerDirectory} -t $ {imageName}. docker push $ {imageName} "" " } } } stage ('Dağıt') { container ('modifiye-jenkins') { sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-deployment.yaml" sh "kubectl apply -f $ {WORKSPACE} $ {kubBackendDirectory} /backend-service.yaml" } } } }Uzay nedeniyle burada ayrıntılı olarak açıklamayacağım. Sürekli dağıtımı tamamlamak için Jenkins'i nasıl çalıştıracağınızı merak ediyorsanız ve öğrenmek istiyorsanız, lütfen Kapsayıcılarda Sürekli Dağıtım Oluşturma ve en iyi uygulamaların ön incelemesine bakın.
Burada Jenkins yazılımını kullanıyorum, ayrıca k8s ortamı için özel olarak tasarlanmış Jenkins-x adlı bir alt projesi var. Ana işlevi otomatik olarak boru hattı kodu oluşturmanıza yardımcı olmaktır (bazı sorularını yanıtlamanız gerekir) ). Kodu kendiniz yazmak istemiyorsanız deneyebilirsiniz.Ayrıntılar için Jenkins-X'e bakınız.
Kod Olarak Hizmet Esnekliği
Hizmetin sağlamlığı da deniyor.İlk iki bölümden farklı olarak bu bölümün bilinen bir adı var.İngilizce'de "Service Resilience" deniyor ve Çince'ye çevrilebilir.Bence servis esnekliği demenin daha uygun olacağını düşünüyorum.
"Hizmet Esnekliği", hizmetin işletim ortamında ağ arızası veya hizmet aşırı yüklenmesi gibi bir sorun olduğunda veya bazı mikro hizmetler çalışmadığında, programın hizmetin bir kısmını veya çoğunu yine de sağlayabileceği anlamına gelir, o zaman hizmet esnekliği diyeceğiz Çok güçlü. Hizmet kalitesinin ölçülmesi için önemli bir göstergedir.
Bu bölümün işlevleri aşağıdaki bölümleri içerir:
-
Hizmet zaman aşımı (Zaman aşımı)
-
Hizmeti Yeniden Deneme (Yeniden Dene)
-
Hizmet mevcut sınırı (Hız Sınırlama)
-
Devre kesici
-
Arıza Enjeksiyonu
-
Bölme izolasyon teknolojisi (Bölme)
Bu bölüm önceki iki bölümden biraz farklıdır: İlk iki bölüm tipik işletme ve bakım görevleridir ve bu bölüm daha önce uygulamanın bir parçasıydı, ancak son yıllarda işletim ve bakıma çok yavaş geçmeye başladı.
Başlangıçta bu işlevler, iş mantığını büyük ölçüde istila eden programın iş mantığı ile karıştırılmış, daha sonra herkes mantığın bu kısmını çıkarmaya ve ayrı parçalara ayırmaya başlamıştır. Belirli bir örnekle açıklayalım (mikro hizmet programına git):
Yukarıdaki resim programın istemci ve sunucu olmak üzere ikiye ayrılmış dizin yapısıdır ve iç yapıları benzerdir. "Ara yazılım" paketi, hizmet esnekliğini uygulayan bir pakettir. "Hizmet" paketi, sunucu tarafındaki mikro hizmetin uygulama işlevi olan ve istemci tarafında sunucu tarafı işlevini çağıran bir iş mantığı paketidir. İstemci altındaki "ara katman yazılımı" paketi dört dosya içerir ve üç işlevi gerçekleştirir: hizmet zaman aşımı, hizmet yeniden deneme ve sigorta. "ClientMiddleware.go" ana giriştir. Sunucunun altındaki "ara katman yazılımı" paketi iki dosya içerir ve hizmetin geçerli sınırı olan bir işlevi uygular. "ServerMiddleware.go" ana giriştir.
Buradaki hizmet esnekliği işlevinin, iş mantığına herhangi bir müdahalede bulunmadan tamamen iş mantığından çıkarıldığını, ayrı bir pakette (ara yazılım) uygulandığını unutmayın. Burada modifikasyon modu kullanılmaktadır. Program uygulamasına ilişkin ayrıntılar için bkz. Mikro Hizmetler Hata Toleransı ve Esnekliği (Hizmet Dayanıklılığı).
Yukarıdakiler, bu işlevleri yerine getirmek için programları kullanmakla ilgilidir, ancak özünde bu işlevler uygulamaya ait olmamalı, altyapı tarafından tamamlanmalıdır. Kabul edilen görüş, Hizmet Ağının bu işlevler için en iyi çözüm olduğudur. Servis şebekesini kullanmanın yolu, bir konfigürasyon dosyası oluşturmak ve ardından konfigürasyon dosyasını çalıştırarak servis şebekesinin işletim ortamını kurmak olan k8s'e benzer. Burada örnek olarak Istio kullanıyoruz Istio çok popüler bir servis ağı yazılımıdır.
Yukarıdaki resim, indirilen Istio yazılımının dizinidir. "Bookinfo" bunun örnek bir programıdır. Bu örnekte, hizmet esnekliğinin nasıl sağlanacağı da dahil olmak üzere Istio'yu kullanmanın çeşitli yollarını gösterir. Ayrıntılar için istio'ya bakın.
Operasyon izleme (İzleme veya Gözlenebilirlik)
Operasyon izleme, operasyon ve bakımın önemli bir parçasıdır ve genellikle aşağıdaki hususları içerir:
-
Log (loglama): Programın çalışması sırasında bilgileri kaydeder;
-
İzleme: Bir taleple ilgili bilgileri, özellikle talep edilen zamanla ilgili bilgileri kaydeder;
-
Metrikler: Yukarıdaki ayrı bilgilerin aksine, burada kaydedilenler, genellikle zaman eksenine göre toplanan biriktirilebilir bilgilerdir.
Genellikle Üç Sütun Gözlemlenebilirlik (Üç Gözlemlenebilirlik Sütunu) diyoruz. Aralarındaki ilişkiyi açıklayan çok iyi bir makale var. Ayrıntılar için lütfen "Ölçümler arasındaki ilişki, izleme ve günlüğe kaydetme" konusuna bakın.
Bu bölümün içeriği biraz tartışmalı olabilir. İlk birkaç parça net çalışma ve bakım çalışması olduğundan, servis esnekliği eskiden geliştirme çalışması olsa da, her zaman bir operasyon ve bakım meselesi olarak kabul edilmiştir ve kodları çok temiz bir şekilde çıkarılabilir. Ancak operasyon izleme farklıdır. Asıl iş hala operasyon ve bakım ile yapılsa da, kodu açıkça çıkarılması zor olan iş mantığı kodu ile karıştırılır.
-
Günlük:
Kodun bu kısmı uygulamadadır, ancak günlük toplama, özet, analiz ve görüntüleme işlemlerinin tamamı ve bakımı ile yapılır. Temsilcisi ünlü ELK serisidir. DevOps'u benimsedikten sonra, buradaki değişiklikler büyük değil, en fazla, toplama aracısı (Aracı), daha kolay hale getirmek için servis ızgarası veya k8s ile daha iyi entegre olur.
-
Dağıtılmış izleme:
Bu kısım biraz servis esnekliği gibidir.Başlangıçta program tarafından tamamlanır ve yavaş yavaş onu uygulamadan izole etmek için ayrı bir kısım haline gelir.Sonunda işin çoğu servis şebekesi tarafından yapılır. Ancak hizmet esnekliği ile aynı şey değildir. Hizmet esnekliği, uygulamalarda çok net bir kesinti sağlayabilir ve dağıtılmış izleme, izlemenin ayrıntı düzeyine bağlıdır. Yalnızca servisler arası takip ise, hiçbir sorun yoktur ve servis şebekesi tarafından yapılabilir. Ancak, hizmetin dahili takibi ise, servis şebekesi güçsüzdür ve yine de bir günlük gibi program kodu tarafından yapılır. Ama bence hizmetler arası izleme en yüksek girdi-çıktı oranına sahip, çoğu durumda yeterli ve hizmetlerin dahili olarak izlenmesine gerek yok.
Ayrıntılar için, lütfen Go mikro hizmet tam bağlantı izlemesinin ayrıntılı açıklamasına bakın.
-
Metrikler:
Gözlemin bu kısmı kümülatif bilgidir. Çoğu durumda, araçlar kurulu olduğu sürece, analiz için veriler toplanabilir. En popüler araç Prometheus'dur.Veri almak için kod yazmanıza gerek yoktur, ancak ihtiyacınız olan bilgiyi hızlı bir şekilde bulmak istiyorsanız, k8'lerin konfigürasyonunun yine de Prometheus'un konfigürasyonuna uyması gerekir, bu yüzden biraz detaylı tasarım yapmanız gerekir. Ayrıntılar için bkz. Prometheus ve Kubernetes: Uygulamalarınızı İzleme.
Elbette, daha ayrıntılı izleme gereksinimleriniz varsa, Prometheus bunları doğrudan karşılayamaz. Şu anda, ihtiyaçlarınızı karşılamak için uygulamaya bazı Prometheus izleme kodu eklemeniz gerekir.
Diğer işler
Kaçırılan başka O&M görevleri var mı?
-
Sürekli Entegrasyon
Birçok kişi, geniş bir tanım kullandığı için sürekli entegrasyonu (CI) DevOps'un önemli bir parçası olarak kabul eder. Dar anlamda, DevOps yalnızca işlemleri ve bakımı içerir. Sürekli entegrasyon (CI) ve sürekli dağıtım (CD) açıkça farklıdır.Sürekli entegrasyon geliştirme işidir, sürekli dağıtım ise işletim ve bakım işidir. Aşağıdaki şekil farkı göstermektedir.
Resim kaynağı: https://www.sonatype.com/products-overview
Şekilde görüldüğü gibi, tüm süreç şu şekildedir:
Programcı, kaynak kodu kaynak kontrol kitaplığından indirir, programı yazar ve tamamlandıktan sonra kodu kaynak kitaplığa gönderir.Sürekli Entegrasyon aracı, kaynak kodunu kaynak kitaplığından indirir, kaynak kodu derler ve ardından çalışma zamanı kitaplığına gönderir ( Depo) ve ardından Sürekli Teslimat aracı Kod Deposundan kod indirir, bir yayın sürümü oluşturur ve bunu farklı işletim ortamlarında (DEV, QA, UAT, PROD gibi) yayınlar.
Şekilde, sol kısım, esas olarak geliştirme ve programcılarla ilgili olan sürekli entegrasyondur; sağ kısım, esas olarak test, çalıştırma ve bakım ile ilgili olan sürekli dağıtımdır. Sürekli teslim (Sürekli Dağıtım), aynı zamanda sürekli dağıtım (Sürekli Dağıtım) olarak da adlandırılır, eğer alt bölümlere ayrılmışlarsa, yine de küçük bir fark vardır, ancak burada, topluca sürekli dağıtım olarak adlandırılan çok fazla ayırt etmiyoruz.
DevOps'a sürekli entegrasyon koymadım çünkü bu makale dar bir yorum kullanıyor, yani sadece işletim ve bakım kısmını içeriyor.
sonuç olarak
Bu makale, DevOps'un kod perspektifinden anlaşılmasını açıklamaktadır, DevOps'un özü, işlem ve bakım yapmak için kod yazmaktır , Ve DevOps'u benimsemek isteyen arkadaşlara yardım etmeyi umarak işletim ve bakımın her bölümü için özel örnekler verdi. DevOps, özellikle çalıştırma ve bakım için geliştirme, işletim ve bakımı büyük ölçüde değiştirdi.
Yakın gelecekte, geliştirme ile işletme ve bakım arasında bir ayrım olmayacak.Tek bir iş var, o da kod yazmak. Tabii ki, geliştirme kodu çiftçileri ve işletme ve bakım kodu çiftçileri olarak alt bölümlere ayrılabilir. İşletme ve bakım çalışmaları kod yazılarak yapılır. Uygulama programı yalnızca iş mantığı kodunu değil, aynı zamanda bir kaynak kodu kitaplığında saklanacak olan işletim ve bakım kodunu da içerir.
Tam kaynak kodu için GitHub bağlantısı:
-
k8sdemo: https://github.com/jfeng45/k8sdemo
-
grpcservice: https://github.com/jfeng45/grpcservice
Orijinal adres:
https://blog.csdn.net/weixin_38748858/article/details/103068797
CSDN, yazar tarafından yayınlama yetkisine sahiptir.
dizin:
https://blog.csdn.net/weixin_38748858/article/details/102758381
https://assets.thoughtworks.com/assets/technology-radar-vol-20-en.pdf
https://jenkins.io/doc/book/pipeline/
https://blog.csdn.net/weixin_38748858/article/details/102967540
https://jenkins-x.io/
https://blog.csdn.net/weixin_38748858/article/details/100781369
https://github.com/istio/istio
https://wu-sheng.github.io/me/articles/metrics-tracing-and-logging.html
https://blog.csdn.net/weixin_38748858/article/details/100586019
https://www.weave.works/blog/prometheus-and-kubernetes-monitoring-your-applications/
Lei Jun, Xiaomi Mi 10'un fiyatından bahsediyor: Pahalı değil, arkadaş edin; Baidu açık kaynağın ilk maske yüz algılama modeli; Ubuntu Kylin 18.04.4 LTS yayınlandı | Geek Manşetleri
Zhao Wei, American University of Sharjah Bilimsel Araştırma Başkan Yardımcısı: Endüstri 4.0'ın temel teknolojisi olan CPS'nin geçmişini ve bugününü aydınlatmak |
Ant Financial'ın AAAI'sinde yer alan kağıtlar açığa çıktı ve dinamik ağ budama yönteminde ve suskun eğitim öncesi ağ budama teknolojisinde önemli gelişmeler var
270 milyon öğrenci evde derslere katılıyor, velilerin görüşleri var ...
6 ayda 0 programlama deneyiminden nasıl veri bilimcisi oldum?
Meng Yan: Salgının neden olduğu askıya alma, blok zinciri ve dijital ekonomiyi daha büyük bir toparlanma başlatacak
