Mikro hizmet mimarileri için CI/CDCI/CD for microservices architectures

Yayın döngüleri daha hızlı mikro hizmet mimarileri başlıca avantajlarından biridir.Faster release cycles are one of the major advantages of microservices architectures. Ancak, iyi bir CI/CD işlem, taahhüt mikro hizmet çevikliği elde olmaz.But without a good CI/CD process, you won't achieve the agility that microservices promise. Bu makalede sorunlarını açıklar ve sorun için aşağıdaki yaklaşımlardan önerir.This article describes the challenges and recommends some approaches to the problem.

CI/CD nedir?What is CI/CD?

Biz CI/CD hakkında konuşurken, ilgili çeşitli işlemleri hakkında gerçekten Başladık: Sürekli tümleştirme, sürekli teslim ve sürekli dağıtım.When we talk about CI/CD, we're really talking about several related processes: Continuous integration, continuous delivery, and continuous deployment.

  • Sürekli Tümleştirme.Continuous integration. Kod değişikliklerinin sık sık ana dalla birleştirilir.Code changes are frequently merged into the main branch. Otomatik derleme ve test işlemleri, ana dalda kod her zaman üretim kalitesinde olduğundan emin olun.Automated build and test processes ensure that code in the main branch is always production-quality.

  • Sürekli teslim.Continuous delivery. CI işlem geçen herhangi bir kod değişikliği, bir üretim ortamına benzer otomatik olarak yayımlanır.Any code changes that pass the CI process are automatically published to a production-like environment. Canlı üretim ortamına dağıtım el ile onayı gerektirir, ancak aksi otomatik.Deployment into the live production environment may require manual approval, but is otherwise automated. Kodunuzun her zaman olmalıdır amaçtır hazır üretime dağıtmak için.The goal is that your code should always be ready to deploy into production.

  • Sürekli dağıtım.Continuous deployment. Kod değişikliklerini önceki iki adımı otomatik olarak dağıtılan, pass üretime.Code changes that pass the previous two steps are automatically deployed into production.

Bir mikro hizmet mimarisi için sağlam bir CI/CD işlem bazı amaçları şunlardır:Here are some goals of a robust CI/CD process for a microservices architecture:

  • Her takım oluşturabilir ve etkileyen veya diğer ekipler kesintiye bağımsız olarak, sahip olan hizmetleri dağıtın.Each team can build and deploy the services that it owns independently, without affecting or disrupting other teams.

  • Bir hizmetin yeni bir sürümü üretim ortamına dağıtılmadan önce doğrulama için geliştirme/test/QA ortamlara dağıtılır.Before a new version of a service is deployed to production, it gets deployed to dev/test/QA environments for validation. Kalite kapıları her aşamada yerine getirilir.Quality gates are enforced at each stage.

  • Bir hizmetin yeni bir sürümü önceki sürümü yan yana dağıtılabilir.A new version of a service can be deployed side by side with the previous version.

  • Yeterli erişim denetimi ilkeleri gerçekleşmiştir.Sufficient access control policies are in place.

  • Kapsayıcılı iş yükleri için üretime dağıtılmadan kapsayıcı görüntülerini güvenebilir.For containerized workloads, you can trust the container images that are deployed to production.

Güçlü bir CI/CD işlem hattı neden önemlidirWhy a robust CI/CD pipeline matters

Geleneksel tek parçalı bir uygulamada, uygulamanın yürütülebilir çıktısı olan bir tek bir derleme işlem hattı yok.In a traditional monolithic application, there is a single build pipeline whose output is the application executable. Bu ardışık düzen halinde, tüm geliştirme iş akışları.All development work feeds into this pipeline. Yüksek öncelikli hata bulunursa, bir düzeltme gerekir tümleşik test ve yayımlanan hangi yeni özellikler sürümü erteleyebilirsiniz.If a high-priority bug is found, a fix must be integrated, tested, and published, which can delay the release of new features. Bu sorunlar, katsayıları iyi belirlenmiş modüllerine sahip olmak ve kod değişikliklerinin etkisini en aza indirmek için özellik dalları kullanarak azaltabilirsiniz.You can mitigate these problems by having well-factored modules and using feature branches to minimize the impact of code changes. Ancak uygulama daha karmaşık büyür ve daha fazla özellik eklenir monoliti sürüm sürecini daha kırılır ve ayırmak büyük olasılıkla eğilimindedir.But as the application grows more complex, and more features are added, the release process for a monolith tends to become more brittle and likely to break.

Mikro hizmet felsefesi hiçbir zaman olmalıdır satır almak için her takım sahip olduğu bir uzun yayın eğitimi.Following the microservices philosophy, there should never be a long release train where every team has to get in line. Birleştirilecek, "B" hizmetindeki değişiklikler için beklemenize gerek kalmadan herhangi bir zamanda bir güncelleştirme "A" serbest bırakabilirsiniz service'ı oluşturan ekip, test ve dağıtılabilir.The team that builds service "A" can release an update at any time, without waiting for changes in service "B" to be merged, tested, and deployed.

CI/CD monoliti diyagramı

Yüksek yayın hızı elde etmek için yayın işlem hattınızı otomatik ve riski en aza indirmek için son derece güvenilir olması gerekir.To achieve a high release velocity, your release pipeline must be automated and highly reliable to minimize risk. Üretim için bir sürüm veya daha fazla kez günlük, gerilemeleri ya da hizmet kesintilerine nadir olması gerekir.If you release to production one or more times daily , regressions or service disruptions must be rare. Aynı zamanda, hatalı bir güncelleştirme dağıtılsın, hızlı bir şekilde geri veya ileri bir hizmetin bir önceki sürüme geri alma için güvenilir bir yol olmalıdır.At the same time, if a bad update does get deployed, you must have a reliable way to quickly roll back or roll forward to a previous version of a service.

ZorluklarChallenges

  • Birçok küçük bağımsız kod tabanları.Many small independent code bases. Her takımın kendi hizmetiyle, kendi derleme işlem hattı oluşturmak için sorumludur.Each team is responsible for building its own service, with its own build pipeline. Bazı Kurumlarda, takımlar ayrı kod depoları kullanabilir.In some organizations, teams may use separate code repositories. Ayrı depoları burada sistem oluşturma konusunda bilgi takımlar arasında yayılır ve kimse kuruluş içindeki tüm uygulama dağıtmak bildiği bir durum neden olabilir.Separate repositories can lead to a situation where the knowledge of how to build the system is spread across teams, and nobody in the organization knows how to deploy the entire application. Örneğin, hızlı bir şekilde yeni bir kümeye dağıtmak ihtiyacınız varsa ne bir olağanüstü durum kurtarma senaryosunda olur?For example, what happens in a disaster recovery scenario, if you need to quickly deploy to a new cluster?

    Risk azaltma: Bu bilgi "her bir takım değil gizlenmemesi için" derlemek ve Hizmetleri dağıtmak için birleşik ve otomatik bir işlem hattı vardır.Mitigation: Have a unified and automated pipeline to build and deploy services, so that this knowledge is not "hidden" within each team.

  • Birden çok dil ve çerçeveleri.Multiple languages and frameworks. Her takıma kendi teknoloji harmanı kullanarak, kuruluş genelinde çalışır bir tek bir yapı işlemi oluşturmak zor olabilir.With each team using its own mix of technologies, it can be difficult to create a single build process that works across the organization. Derleme işlemi, tüm takımlar, kendi seçtikleri dil veya çerçeve için uyum kadar esnek olması gerekir.The build process must be flexible enough that every team can adapt it for their choice of language or framework.

    Risk azaltma: Her hizmet için yapı işlemini kapsayıcılı hale getirme.Mitigation: Containerize the build process for each service. Bu şekilde, yapı sistemi yalnızca kapsayıcılar çalıştırılabilmesi gerekir.That way, the build system just needs to be able to run the containers.

  • Tümleştirme ve yük testi.Integration and load testing. Kendi belirlediğiniz hızda güncelleştirmeler takımlarla sağlam-test etme, özellikle Hizmetleri bağımlılıkları diğer hizmetlere sahip olduğunda uca tasarlamak için zor olabilir.With teams releasing updates at their own pace, it can be challenging to design robust end-to-end testing, especially when services have dependencies on other services. Her takımın kendi tam kümesini test etmek için üretim ölçekler, aşamasında çalışacak düşüktür, bu nedenle Ayrıca, bir tam üretim kümesini çalıştırmak pahalı olabilir.Moreover, running a full production cluster can be expensive, so it's unlikely that every team will run its own full cluster at production scales, just for testing.

  • Sürüm Yönetimi.Release management. Her takım bir güncelleştirme üretim ortamına dağıtmak başlatabilmeniz gerekir.Every team should be able to deploy an update to production. Bu, her ekip üyesi, bunu yapmak için izinlere sahip olduğundan gelmez.That doesn't mean that every team member has permissions to do so. Ancak bir merkezi sürüm Yöneticisi rolüne sahip dağıtımları hızını azaltabilir.But having a centralized Release Manager role can reduce the velocity of deployments.

    Risk azaltma: Daha fazla, CI/CD işlem otomatik ve güvenilir, az orada olması gereken bir yönetim yetkilisi gereksinimini.Mitigation: The more that your CI/CD process is automated and reliable, the less there should be a need for a central authority. Küçük hata düzeltmeleri ile karşılaştırması büyük özellik güncelleştirmeleri serbest bırakmak için farklı ilkeler olabilir. Bununla birlikte.That said, you might have different policies for releasing major feature updates versus minor bug fixes. Merkeze bağlı sıfır idare anlamına gelmez.Being decentralized doesn't mean zero governance.

  • Hizmet güncelleştirmeleri.Service updates. Bir hizmetin yeni bir sürüme güncelleştirdiğinizde, bağımlı diğer hizmetleri sonu olmamalıdır.When you update a service to a new version, it shouldn't break other services that depend on it.

    Risk azaltma: Mavi-yeşil veya kanarya sürümü gibi teknikler dağıtım hataya neden olmayan değişiklikler için kullanın.Mitigation: Use deployment techniques such as blue-green or canary release for non-breaking changes. API değişiklikler için yeni sürümü önceki sürümü yan yana dağıtın.For breaking API changes, deploy the new version side by side with the previous version. Bu şekilde, önceki API'sini kullanmanın Hizmetleri güncelleştirilebilir ve yeni API için test.That way, services that consume the previous API can be updated and tested for the new API. Bkz: Hizmetleri güncelleştirmeaşağıdaki.See Updating services, below.

Monorepo çoklu depo karşılaştırmasıMonorepo vs. multi-repo

Bir CI/CD iş akışı oluşturmadan önce kod tabanının nasıl yapılandırılmış ve yönetilen bilmeniz gerekir.Before creating a CI/CD workflow, you must know how the code base will be structured and managed.

  • Takımlar, ayrı depolarında veya bir monorepo (tek depo) çalışıyor mu?Do teams work in separate repositories or in a monorepo (single repository)?
  • Dallanma stratejisi nedir?What is your branching strategy?
  • Üretim için kimlerin kod gönderebilir?Who can push code to production? Yayın Yöneticisi rolü var mı?Is there a release manager role?

Monorepo yaklaşım ayrıcalık elde etme ancak avantajlar ve dezavantajlar her ikisine de vardır.The monorepo approach has been gaining favor but there are advantages and disadvantages to both.

  MonorepoMonorepo Birden çok depoMultiple repos
AvantajlarıAdvantages Kod paylaşmaCode sharing
Kod ve araçları kullanarak daha kolayEasier to standardize code and tooling
Yeniden düzenleme kod daha kolayEasier to refactor code
Bulunabilirlik - kodun tek bir görünümDiscoverability - single view of the code
Takım başına net sahipliğiClear ownership per team
Potansiyel olarak daha az çakışmaları BirleştirPotentially fewer merge conflicts
Mikro ayırma uygulanmasına yardımcı olurHelps to enforce decoupling of microservices
ZorluklarChallenges Paylaşılan kod değişiklikleri birden çok mikro hizmetleri etkileyebilirChanges to shared code can affect multiple microservices
Büyük potansiyeli birleştirme çakışmalarıGreater potential for merge conflicts
Araç, büyük kod tabanına Ölçeklendirmesi gerekirTooling must scale to a large code base
Erişim denetimiAccess control
Daha karmaşık dağıtım işlemiMore complex deployment process
Kod paylaşmak zorHarder to share code
Kodlama standartları zorlamak zorHarder to enforce coding standards
Bağımlılık yönetimiDependency management
Kod temel, zayıf bulunabilirliği yayınıkDiffuse code base, poor discoverability
Paylaşılan altyapı eksikliğiLack of shared infrastructure

Güncelleştirme HizmetleriUpdating services

Üretimde olan bir hizmeti güncelleştirmek için çeşitli stratejileri vardır.There are various strategies for updating a service that's already in production. Burada üç yaygın seçenekleri ele alır: Güncelleştirme ve mavi-yeşil dağıtım vamp alınıyor.Here we discuss three common options: Rolling update, blue-green deployment, and canary release.

Güncelleştirmeleri almaRolling updates

Sıralı bir güncelleştirmede yeni bir hizmetin örneklerine dağıtmak ve yeni örnekleri isteklerini hemen almak başlatın.In a rolling update, you deploy new instances of a service, and the new instances start receiving requests right away. Yeni örnekleri oluştukça önceki örneği kaldırılır.As the new instances come up, the previous instances are removed.

Örnek.Example. Bir dağıtım için pod spec güncelleştirdiğinizde Kubernetes'te, varsayılan davranışı sıralı güncelleştirmeler gelir.In Kubernetes, rolling updates are the default behavior when you update the pod spec for a Deployment. Güncelleştirilmiş pod'ları için yeni bir REPLICASET dağıtım denetleyiciyi oluşturur.The Deployment controller creates a new ReplicaSet for the updated pods. Ardından, istenen çoğaltma sayısını korumak için eski bir ölçeklendirme sırasında yeni REPLICASET ölçeklendirir.Then it scales up the new ReplicaSet while scaling down the old one, to maintain the desired replica count. Yeni bir tane hazır olana kadar bu eski pod'ları silinmez.It doesn't delete old pods until the new ones are ready. Bir güncelleştirme gerekirse geri alabilirsiniz, böylece Kubernetes güncelleştirme bir geçmişini tutar.Kubernetes keeps a history of the update, so you can roll back an update if needed.

Örnek.Example. Azure Service Fabric, varsayılan olarak sıralı güncelleştirme stratejisi kullanır.Azure Service Fabric uses the rolling update strategy by default. Bu strateji mevcut API'lere değiştirmeden bir sürümü yeni özellikler içeren bir hizmet dağıtmak için idealdir.This strategy is best suited for deploying a version of a service with new features without changing existing APIs. Service Fabric, uygulama türünü düğümler veya bir güncelleştirme etki alanının bir alt kümesine güncelleştirerek bir yükseltme dağıtımı başlar.Service Fabric starts an upgrade deployment by updating the application type to a subset of the nodes or an update domain. Tüm etki alanları yükseltilene kadar ardından İleri sonraki güncelleştirme etki yapar.It then rolls forward to the next update domain until all domains are upgraded. Bir yükseltme etki alanını güncelleştirmek başarısız olursa, uygulama türünün tüm etki alanları arasında önceki sürüme geri alır.If an upgrade domain fails to update, the application type rolls back to the previous version across all domains. Bir uygulama birden çok hizmetlerle yazın (ve tüm hizmetleri bir tek yükseltme dağıtımının bir parçası güncelleştirilir) dikkat hatalarına daha yatkındır.Be aware that an application type with multiple services (and if all services are updated as part of one upgrade deployment) is prone to failure. Güncelleştirmek bir hizmet başarısız olursa tüm uygulama önceki sürüme geri alınır ve diğer hizmetleri güncelleştirilmez.If one service fails to update, the entire application is rolled back to the previous version and the other services are not updated.

Güncelleştirmeleri çalışırken, bir güncelleştirme işlemi sırasında bir karışımı eski ve yeni sürümleri çalıştıran ve trafik almasını, zorluktur.One challenge of rolling updates is that during the update process, a mix of old and new versions are running and receiving traffic. Bu süre boyunca herhangi bir istek iki sürüm birini yönlendirilir.During this period, any request could get routed to either of the two versions.

API değişiklikler için bir önceki sürümünün tüm istemciler güncelleştirilene kadar iki sürümünü yan yana desteklemeyi alışkanlıktır.For breaking API changes, a good practice is to support both versions side by side, until all clients of the previous version are updated. Bkz: API sürümü oluşturma.See API versioning.

Mavi-yeşil dağıtımBlue-green deployment

Mavi-yeşil dağıtım içinde yeni sürümü önceki sürümün yanına dağıtın.In a blue-green deployment, you deploy the new version alongside the previous version. Yeni sürüm doğruladıktan sonra önceki sürümden tek seferde tüm trafiği yeni sürüme geçin.After you validate the new version, you switch all traffic at once from the previous version to the new version. Anahtarından sonra herhangi bir sorun için uygulamayı izleyin.After the switch, you monitor the application for any problems. Bir sorun yaşanırsa eski sürüme takas edebilirsiniz.If something goes wrong, you can swap back to the old version. Herhangi bir sorun yok varsayıldığında, eski sürümü silebilirsiniz.Assuming there are no problems, you can delete the old version.

İki özdeş ortamları sağlama ile daha geleneksel bir tek parçalı veya N katmanlı uygulama, mavi-yeşil dağıtım genellikle geliyordu.With a more traditional monolithic or N-tier application, blue-green deployment generally meant provisioning two identical environments. Yeni sürüm bir hazırlama ortamına dağıtma sonra hazırlama ortamına istemci trafiği yeniden yönlendirmeniz — tarafından VIP takas gibi adresleri.You would deploy the new version to a staging environment, then redirect client traffic to the staging environment — for example, by swapping VIP addresses. Bu nedenle genellikle güncelleştirmeyi aynı ortama dağıtmanız ve hizmet bulma mekanizması kullanarak bir mikro hizmet mimarisinde güncelleştirmeleri mikro hizmet düzeyinde gerçekleşir.In a microservices architecture, updates happen at the microservice level, so you would typically deploy the update into the same environment and use a service discovery mechanism to swap.

Örnek.Example. Kubernetes'te, mavi-yeşil dağıtımlarına yapmak için ayrı bir küme sağlamanız gerekmez.In Kubernetes, you don't need to provision a separate cluster to do blue-green deployments. Bunun yerine, seçici yararlanabilir.Instead, you can take advantage of selectors. Yeni bir pod spec ve farklı bir etiket kümesi ile yeni bir dağıtım kaynağı oluşturun.Create a new Deployment resource with a new pod spec and a different set of labels. Önceki dağıtım noktaları için hizmet silmesini veya olmadan bu dağıtımı oluşturun.Create this deployment, without deleting the previous deployment or modifying the service that points to it. Yeni pod'ların çalışan sonra hizmetin Seçici yeni dağıtım eşleşecek şekilde güncelleştirebilirsiniz.Once the new pods are running, you can update the service's selector to match the new deployment.

Mavi-yeşil dağıtım bir dezavantajı (güncelleştirme sırasında iki kez olarak birçok pod'ları hizmeti için geçerli ve sonraki) çalıştığını ' dir.One drawback of blue-green deployment is that during the update, you are running twice as many pods for the service (current and next). Pod'ların miktarda CPU veya bellek kaynağı gerekiyorsa, kaynak tüketimini geçici olarak işlemek için kümeyi ölçeklendirme gerekebilir.If the pods require a lot of CPU or memory resources, you may need to scale out the cluster temporarily to handle the resource consumption.

VampCanary release

Kanarya sürümde, az sayıda istemciyi güncelleştirilmiş bir sürümü alma.In a canary release, you roll out an updated version to a small number of clients. Ardından tüm istemcilere sunulmadan önce yeni bir hizmet davranışını izleyin.Then you monitor the behavior of the new service before rolling it out to all clients. Bu, denetimli bir biçimde yavaş bir sunum yapmak için tüm müşteri etkilenmeden önce gerçek veriler ve sorunları inceleyin sağlar.This lets you do a slow rollout in a controlled fashion, observe real data, and spot problems before all customers are affected.

Dinamik olarak hizmet farklı sürümlerini istekleri yönlendirmeyi gerekir çünkü bir vamp mavi-yeşil veya çalışırken güncelleştirme yönetmek için daha karmaşıktır.A canary release is more complex to manage than either blue-green or rolling update, because you must dynamically route requests to different versions of the service.

Örnek.Example. Kubernetes, bir hizmeti iki çoğaltma kümesi (her sürümü için bir tane) span ve yineleme sayısını el ile ayarlamak için yapılandırabilirsiniz.In Kubernetes, you can configure a Service to span two replica sets (one for each version) and adjust the replica counts manually. Ancak, bu yaklaşım çok parçalı, Kubernetes yük şekli nedeniyle pod'ları arasında dengeler.However, this approach is rather coarse-grained, because of the way Kubernetes load balances across pods. Örneğin, toplam 10 çoğaltmalar varsa, yalnızca % 10 halinde trafik kaydırabilirsiniz.For example, if you have a total of 10 replicas, you can only shift traffic in 10% increments. Ağ hizmeti kullanıyorsanız, daha karmaşık bir vamp stratejisi uygulamak için hizmet kafes yönlendirme kurallarını kullanabilirsiniz.If you are using a service mesh, you can use the service mesh routing rules to implement a more sophisticated canary release strategy.

Sonraki adımlarNext steps

Azure'da Kubernetes çalışan mikro hizmetler için belirli bir CI/CD uygulamalarını öğrenin.Learn specific CI/CD practices for microservices running on Kubernetes.