GitOps repo yansıtması

Cluster’da yaptığınız bir değişikliği repo’ya yazmazsanız, GitOps controller sonraki reconcile sırasında repo’daki durumu geri uygular.

YEKE, onaylanan değişikliğin repo’daki YAML karşılığını da günceller. İşlemin doğrudan mı yoksa öneri branch’i üzerinden mi ilerleyeceğini cluster’ın repo bağlantısı belirler.

• Apply her hâlde olur ve geri alınmaz. Yansıtma apply'dan sonra koşar. Repo tarafı düşerse operasyon iptal edilmez — acil işi ikincil bir sistemin arızası yüzünden geri almak yanlış öncelik olurdu.
• Repo tarafı ayrı raporlanır. Operasyonun kendi hâli vardır: yansıdı, karşılığı bulunamadı, yazılamadı, ya da uygulanabilir değil. Bu hâl operasyon kartında ve denetim izinde durur — sessiz kaybı en azından gürültülü kayba çevirir.
• Commit izlenen branch'e gider. Doğrudan, reconciler'ın izlediği branch'e. Sebebi tek cümle: arızayı yalnız o branch'in içeriği çözer, merge edilmemiş bir öneri reconcile'ı durdurmaz.
• Branch korumalıysa iş yarım kalır ve bunu söyler. Push reddedilirse yansıtma bir öneri branch'ine düşer ve hâl "yansıdı" olmaz. Ekranın cümlesi yumuşatılmaz: değişiklik cluster'a uygulandı, siz merge edene kadar bir sonraki reconcile bunu geri alabilir.

İkinci katman drift'tir: yansıtmanın bulamadığı ya da yazamadığı her operasyon, bir sonraki drift okumasında görünür bir fark olarak durur. Yansıtma önler, drift kaçanı yakalar.

• 1 · Yönetim → GitOps repo'ları. Sayfa yalnız admin rolünde açılır; GitOps modu lisanslı bir kalemdir.
• 2 · Repo'yu kaydedin. Üç alan: remote adresi, izlenen branch, kapsam yolu. Alanların ayrıntısı aşağıdaki tabloda.
• 3 · YEKE bir deploy key üretir. Özel yarısı core'da kalır ve hiçbir ekranda, hiçbir indirmede görünmez. Public yarısı her zaman görünür ve kopyalanabilir; satırın sonundaki yeke-gitops yorumu, sağlayıcı ekranında anahtarı tanımanız içindir.
• 4 · Public key'i sağlayıcınıza YAZMA yetkisiyle ekleyin. Bu adım YEKE'nin dışında yapılır ve sıranın en kolay atlanan yeri burasıdır. Aradığınız şey repo düzeyinde bir deploy key ve o kaydın yazma kutusu; menü adları ve yerleşim sağlayıcıya göre değişir. Salt-okuma bir anahtarla bağlantı kurulur ama commit atılamaz.
• 5 · Bağlantıyı sınayın. Kurulumun gerçekten çalıştığını ölçen tek jest budur; bir sonraki bölüm ne ölçtüğünü anlatıyor.
• 6 · Cluster'ı repo'ya bağlayın. Cluster satırının eylem menüsündeki GitOps bağından: repo seçilir, isterseniz kapsam yolu, namespace ve kind ile daraltırsınız. Bağ o cluster'ın yazma custody'sini değiştirir ve cluster kartında bir satır olarak yazılıdır.

Kaydın alanları

Host kimliği

İlk bağlantıda sunucunun sunduğu host key sabitlenir. YEKE onu doğrulamaz: parmak izini sağlayıcınızın yayımladığı değerle siz karşılaştırırsınız. Kart bunu saklamaz, gövdesine yazar.

Sabitlenmiş bir host kimliği, anahtarınızın kabul edildiği anlamına gelmez. İkisi ayrı ölçüm ve ekran onları aynı yeşile katlamaz.

Host key değişirse yeni fingerprint’i sağlayıcınızdan veya sunucu yöneticinizden alın ve elle girin. YEKE, bağlantıda aldığı değerle eşleşirse yeni anahtarı kaydeder.

Bağı daraltmak

Namespace ve kind daraltmalarında iki hâl bilerek ayrıdır: daraltma yok ile boş liste. Boş liste "hiçbir namespace kapsamda değil" demektir; pencere bunu kaydetmeden önce yazar.

Kapsam yolunu bir alt dizine daraltmak beyanın kimliğini bozmaz. Kapsamınızın üstünde kalan kustomization.yaml dosyaları kimlik zinciri için yine okunur — namespace: gibi bir dönüştürücü üst dizinde dursa da beyanın gerçek kimliği doğru çözülür. O dosyalar korpusa karışmaz: yalnız kimlik çözücüsü görür, modele giden dosya listesine ve render ağacına girmez.

• Bağlantı kuruldu mu. Remote'a ulaşılıyor mu, host kimliği sabitlendi mi.
• Anahtar YAZMA yetkisi taşıyor mu. Sağlayıcı anahtarı kabul ediyor mu ve o anahtarla yazılabiliyor mu. Salt-okuma bir anahtar bu satırda ayrı görünür — "bağlandı" yazıp geçmez.
• Kapsam yolu repo'da karşılık buluyor mu. Kapsamın altındaki dosya sayısı döner; sıfır dosya bir uyarıdır.

Test edilmemiş bağlantı ile başarısız bağlantı ayrı gösterilir. Eksik ayarları ilk operasyondan önce bulmak için bağlantı testini çalıştırın.

Aynı ayrım dosya sayısında da geçerli: reddedilen bir sınamada kapsamın dosya sayısı sıfır değil, boş döner. "Baktım ve boştu" başka, "bakamadım" başkadır.

• Hangi dosya, hangi satırlar, hangi branch. Repo farkı kartın parçasıdır ve onayladığınız planın özetine girer — onayladığınız şey sonradan sessizce değişemez.
• Şablonlu kurulumda değer sürülür, şablon sürülmez. helm ya da kustomize yerleşiminde kart hangi girdi değerinin değişeceğini gösterir; şablonun kendisine dokunulmaz. Doğrulama da iddiaya bırakılmaz: düzenlemeden sonra üretilen nesne uygulanan nesneyle eşleşmiyorsa öneri reddedilir.
• Karşılık bulunamazsa bu bilgidir, engel değil. Operasyon yine uygulanır, kart repo'da bir karşılık bulunamadığını söyler ve repo'yu elle güncellemeniz gerekebileceğini yazar. "Karşılığı yok" ile "vardı ama yazamadım" iki ayrı hâldir.

Karşılığı bulan şey önce mekaniktir: kapsamdaki beyanlar okunur ve nesne kimliğiyle (apiVersion, kind, namespace, ad) eşleştirilir — dosya adının nesne adıyla ilgisi olması gerekmez. Yalnız yerleşim şablonluysa ya da repo'nun geleneği mekanik olarak okunamıyorsa modele başvurulur, ve modele giden şey dosya yollarıdır: manifest gövdeniz gitmez, modelin ürettiği metin de dosyaya inmez. Modelin çıktısı bir öneridir ve kod onu çalıştırarak sınar.

• Bir denetleyicinin sahip olduğu nesne kapsamın dışındadır. Bir pod'u sildiğinizde repo'ya hiç bakılmaz: klon yok, onay kutusu yok, render yok. Ölçüt kind adı değil nesnenin şekli — pod'u ReplicaSet, onu da Deployment yaratmıştır ve repo'da duran beyan o Deployment'ın beyanıdır. Kartın cümlesi de bunu söyler: "bakamadım" ya da "repo'da yok" değil, bakılacak bir şey yok.
• "Repo'ya yansıtma" kutusunu kaldırabilirsiniz. Ürün varsayılanı açık — yansıtma ürünün vaadi, kapatmak bilinçli bir sapmadır. Repo başına bu varsayılanı GitOps repo ayarlarından kapatabilirsiniz: o repo'ya bağlı cluster'larda kutu kapalı gelir, plan repo'ya bakmadan kurulur (daha hızlı), kutuyu işaretlediğinizde plan yeniden kurulup repo karşılığını gösterir. Kart, kutunun repo varsayılanıyla mı yoksa sizin seçiminizle mi kapalı olduğunu ayrı yazar ve kayıt bunu taşır. Deneysel bir iş yaparken kutuyu kaldırırsınız: operasyon cluster'a uygulanır, repo'ya hiçbir şey inmez.
• Kutu onaydan önce gelir ve onayladığınız planın parçasıdır. Durumu plan özetine girer, yani kayıt "istemedim" der, "unuttum" demez.
• Kapalıyken repo yarısı hiç hesaplanmaz. Klon atılmaz, render koşmaz, modele gidilmez. Ölçülebilir bir farkı da var: canlı bir sunucuda aynı plan 1307 ms yerine 51 ms'de kuruldu.
• Kutu kapalıyken çakışan beyan uyarısı üretilmez. Repo varsayılanı kapalıysa bu uyarı o repo için varsayılan olarak susar. Beyan edilmiş bir sınır; kararınız plan özetinde ve denetim izinde durur.

• İşaret, onayladığınız planın parçasıdır. Kutunun durumu plan özetine girer: onayladığınız kapsam sonradan sessizce büyüyemez.
• Yeni dosyanın yerini gelenek belirler, içeriğini işlemin kendisi. Dosya adı deseni ve dizin düzeni repo'dan okunur; okunamıyorsa yalnız yol önerilir. Öneri ancak build ile doğrulanırsa kabul edilir — render nesneyi gerçekten üretmiyorsa öneri reddedilir ve hâl "karşılığı yok"ta kalır.
• Silmede de ölçüt build'dir: düzenlemeden sonra render nesneyi hâlâ üretiyorsa repo'ya yazılmaz.
• Overlay'in son nesnesi ayrıca sorulur. Sildiğiniz nesne, bulunduğu kustomization'ın ürettiği son nesneyse kartta ikinci bir kutu doğar: "bu overlay bütünüyle kalksın mı". Varsayılanı kapalı ve birinci kutudan ayrı — overlay kaldırmak, bir nesne silmekten başka bir karardır ve tek onayın altına gizlenemez. İşaretlenirse üst kustomization'daki referans da düşer; düşürülemiyorsa kaldırma reddedilir, çünkü yarım bir kaldırma o kapsamın tamamının build'ini düşürür.
• Geride kalan referanslar sayılır, düzenlenmez. Sildiğiniz nesneye repo'da başka bildirimler bağlıysa — bir rota onu hedefliyorsa, bir birim onun iddiasını kullanıyorsa — kart bunları onaydan önce listeler. Hiçbirine dokunulmaz ve bu bilinçli bir karar: bir referansı düzeltmenin doğru yolu tek değil, ve YEKE sizin yerinize seçmez. Hedef başka bir namespace'teyse namespace/ad biçiminde yazılır; bildirimin etkin namespace'i repo'dan çözülemiyorsa kart bunu "belirsiz" der, çözülmüş gibi göstermez.

• Yorumlarınız, girintiniz, akış biçiminiz yerinde kalır. Girinti genişliği, dizi girintisi ve skalerin tırnağı dosyanın kendi geleneğinden okunur. Değişen satırın dışında hiçbir şey yeniden biçimlenmez — doğrudan commit modelinde gürültü bir öneride değil, izlenen branch'te görünürdü.
• Kustomize bakımı. Bir beyan silindiğinde kustomization.yaml'daki karşılığı da düşer: resources, patches, replacements ve üreteç girdileri dâhil.
• Emin olunamayan girdiye dokunulmaz. Yalnızca silinen nesneyi hedeflediğinden emin olunamayan bir girdi olduğu gibi bırakılır ve size gösterilir.
• Yazılamayacak yerde yanlış yazılmaz. Düzenlenecek yol bir anchor/alias'tan geçiyorsa ya da etiketli bir düğümün altındaysa düzenleme hiç üretilmez: yansıtma "yazılamadı" hâlini taşır, operasyon durmaz, iz kalır. Sebep açık — çözmek, onaylamadığınız ikinci bir yeri değiştirmek olurdu.

• Ayrıştırılamayan bir dosya atlandığı için, o dosyada duran bir referans da taranamıyor: silinen bir nesneye orada bağlı kalan bir bildirim kartta listelenmez. Kart okunamayan dosyayı adıyla söyler, yani sessiz değildir; ama o dosyanın içeriği ölçülmemiştir.
• Helm chart'ına YENİ nesne eklemek desteklenmiyor. Chart'ın ürettiği bir nesnenin değerini güncellemek çalışır; yeni bir şablon ve values girdisi üretmek "uygulanabilir değil" olarak raporlanır. Şablon yazmak, doğrulanamayacak bir alandır.
• Şablonun kendisi düzenlenmez. YEKE değere yazar, şablona yazmaz.
• Karışık fiilli planda onay kutusu kartın tamamını kapsar. Aynı planda hem güncelleme hem silme varsa ve kutu işaretsizse güncellemeler de repo'ya yansımaz. Bir plan tek bir niyettir; yarısını indirmek kartı "hangi yarısı indi" demeye zorlardı. Kapsam dışında kalan nesneler — bir denetleyicinin sahip olduğu pod gibi — bu hesaba girmez.
• YEKE reconciler'ı tetiklemez. Senkronu zorlamaz, Argo CD / Flux nesnelerini okumaz, senkron durumunu göstermez. Teslimat sizin aracınızın işi.
• Bağlı bir repo silinemez. Önce cluster bağlarını kaldırırsınız ve kural sunucuda durur — API'yi doğrudan çağırsanız da geçerli. Repo kaydını sildiğinizde sağlayıcıdaki public key yerinde kalır; onu elle kaldırmak sizde.