ProHoster > Blog > yönetim > Kubernetes ipuçları ve püf noktaları: yerel geliştirme ve Telepresence hakkında

Kubernetes ipuçları ve püf noktaları: yerel geliştirme ve Telepresence hakkında

Kubernetes ipuçları ve püf noktaları: yerel geliştirme ve Telepresence hakkında

Kubernetes'te mikro hizmetlerin geliştirilmesiyle ilgili giderek daha fazla soru alıyoruz. Geliştiriciler, özellikle de yorumlanmış dillerin geliştiricileri, en sevdikleri IDE'deki kodu hızlı bir şekilde düzeltmek ve derleme/dağıtım için beklemeden, yalnızca F5 tuşuna basarak sonucu görmek ister. Monolitik bir uygulama söz konusu olduğunda, bir veritabanını ve bir web sunucusunu (Docker, VirtualBox'ta...) yerel olarak kurmak ve ardından hemen geliştirmenin keyfini çıkarmak yeterliydi. Monolitlerin mikro hizmetlere dönüştürülmesi ve Kubernetes'in gelişiyle, birbirlerine bağımlılıkların ortaya çıkmasıyla her şey biraz daha zorlaştı. Bu mikro hizmetlerin sayısı arttıkça sorunlar da artar. Geliştirmenin tadını yeniden çıkarmak için bir veya iki Docker konteynerinden fazlasını, hatta bazen bir düzineden fazlasını yükseltmeniz gerekir... Genel olarak tüm bunlar, aynı zamanda güncel tutulması gerektiğinden oldukça fazla zaman alabilir. .

Farklı zamanlarda soruna farklı çözümler denedik. Ve birikmiş geçici çözümlerle veya sadece "koltuk değneğiyle" başlayacağım.

1. Koltuk değnekleri

Çoğu IDE, FTP/SFTP kullanarak kodu doğrudan sunucuda düzenleme yeteneğine sahiptir. Bu yol çok açık ve hemen onu kullanmaya karar verdik. Onun özü şu şekilde özetlenebilir:

  1. Geliştirme ortamları bölmesinde (geliştirme/inceleme), SSH erişimine sahip ve uygulamayı taahhüt edecek/dağıtacak geliştiricinin genel SSH anahtarını ileten ek bir kapsayıcı başlatılır.
  2. Başlangıç ​​aşamasında (konteyner içinde) prepare-app) kodu aktarın emptyDiruygulama kapsayıcılarından ve SSH sunucusundan koda erişebilmek için.

Kubernetes ipuçları ve püf noktaları: yerel geliştirme ve Telepresence hakkında

Böyle bir planın teknik uygulamasını daha iyi anlamak için Kubernetes'teki ilgili YAML yapılandırmalarının parçalarını sunacağım.

konfigürasyonları

1.1. değerler.yaml

ssh_pub_key:
  vasya.pupkin: <ssh public key in base64>

öyle vasya.pupkin değişkenin değeridir ${GITLAB_USER_LOGIN}.

1.2. dağıtım.yaml

...
{{ if eq .Values.global.debug "yes" }}
      volumes:
      - name: ssh-pub-key
        secret:
          defaultMode: 0600
          secretName: {{ .Chart.Name }}-ssh-pub-key
      - name: app-data
        emptyDir: {}
      initContainers:
      - name: prepare-app
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
        volumeMounts:
        - name: app-data
          mountPath: /app-data
        command: ["bash", "-c", "cp -ar /app/* /app-data/" ]
{{ end }}
      containers:
{{ if eq .Values.global.debug "yes" }}
      - name: ssh
        image: corbinu/ssh-server
        volumeMounts:
        - name: ssh-pub-key
          readOnly: true
          mountPath: /root/.ssh/authorized_keys
          subPath: authorized_keys
        - name: app-data
          mountPath: /app
        ports:
        - name: ssh
          containerPort: 22
          protocol: TCP
{{ end }}
      - name: backend
        volumeMounts:
{{ if eq .Values.global.debug "yes" }}
        - name: app-data
          mountPath: /app
{{ end }}
        command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"]
...

1.3. secret.yaml

{{ if eq .Values.global.debug "yes" }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Chart.Name }}-ssh-pub-key
type: Opaque
data:
  authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}"
{{ end }}

Son dokunuş

Bundan sonra geriye sadece transfer etmek kalıyor gerekli gitlab-ci.yml değişkenleri:

dev:
  stage: deploy
  script:
   - type multiwerf && source <(multiwerf use 1.0 beta)
   - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
   - werf deploy
     --namespace ${CI_PROJECT_NAME}-stage
     --set "global.env=stage"
     --set "global.git_rev=${CI_COMMIT_SHA}"
     --set "global.debug=yes"
     --set "global.username=${GITLAB_USER_LOGIN}"
 tags:
   - build

Voila: dağıtımı başlatan geliştirici hizmet adına göre bağlanabilir (kümeye güvenli bir şekilde erişim izni nasıl verilir, biz zaten söyledik) masaüstünüzden SFTP aracılığıyla kopyalayın ve kodun kümeye teslim edilmesini beklemeden düzenleyin.

Bu tamamen işe yarayan bir çözümdür ancak uygulama açısından bakıldığında bariz dezavantajları vardır:

  • gelecekte okumayı zorlaştıran Dümen haritasının iyileştirilmesi ihtiyacı;
  • yalnızca hizmeti dağıtan kişi tarafından kullanılabilir;
  • daha sonra onu yerel dizinle kodla senkronize etmeyi ve Git'e kaydetmeyi hatırlamanız gerekir.

2. Telebulunma

Proje telepresence oldukça uzun zamandır biliniyor, ancak biz, dedikleri gibi, "bunu pratikte ciddi şekilde denemeye fırsat bulamadık." Ancak talep işini yaptı ve artık blogumuzun okuyucuları için yararlı olabilecek deneyimlerimizi paylaşmaktan mutluluk duyuyoruz - özellikle de merkezde henüz Telepresence hakkında başka materyal bulunmadığından.

Kısacası her şeyin o kadar da korkutucu olmadığı ortaya çıktı. Geliştiricinin yürütmesi gereken tüm eylemleri, adlı bir Helm grafiği metin dosyasına yerleştirdik. NOTES.txt. Böylece, hizmeti Kubernetes'e dağıttıktan sonra geliştirici, GitLab iş günlüğünde yerel geliştirme ortamını başlatma talimatlarını görür:

!!! Разработка сервиса локально, в составе Kubernetes !!!

* Настройка окружения
* * Должен быть доступ до кластера через VPN
* * На локальном ПК установлен kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ )
* * Получить config-файл для kubectl (скопировать в ~/.kube/config)
* * На локальном ПК установлен telepresence ( https://www.telepresence.io/reference/install )
* * Должен быть установлен Docker
* * Необходим доступ уровня reporter или выше к репозиторию https://gitlab.site.com/group/app
* * Необходимо залогинится в registry с логином/паролем от GitLab (делается один раз):

#########################################################################
docker login registry.site.com
#########################################################################

* Запуск окружения

#########################################################################
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8
#########################################################################

Sonuncusu hariç, bu talimatta açıklanan adımlar üzerinde ayrıntılı olarak durmayacağız. Telepresence'ın lansmanı sırasında ne olur?

Telepresence'la çalışmak

Başlangıçta (yukarıdaki talimatlarda belirtilen son komutu kullanarak) şunları ayarladık:

  • mikro hizmetin çalıştığı ad alanı;
  • sızmak istediğimiz dağıtımın ve konteynerin adları.

Geriye kalan argümanlar isteğe bağlıdır. Hizmetimiz Kubernetes API ile ve Kubernetes API için etkileşime giriyorsa Hizmet Hesabı oluşturuldusertifikaları/belirteçleri masaüstümüze yerleştirmemiz gerekiyor. Bunu yapmak için seçeneği kullanın --mount=true (ya --mount=/dst_path), bu da kökü (/) Kubernetes kapsayıcısından masaüstümüze bağlayacak. Bundan sonra (işletim sistemine ve uygulamanın nasıl başlatıldığına bağlı olarak) kümedeki "anahtarları" kullanabiliriz.

İlk olarak, bir uygulamayı çalıştırmak için en evrensel seçeneğe - Docker kapsayıcısında - bakalım. Bunu yapmak için anahtarı kullanacağız --docker-run ve kodun bulunduğu dizini konteynere ekleyin: -v `pwd`:/app

Lütfen bunun proje dizininden çalıştırıldığını varsaydığını unutmayın. Uygulama kodu dizine eklenecek /app bir kapta.

Sonraki: -v /tmp/app/var/run/secrets:/var/run/secrets — sertifikayı/belirteci içeren dizini bir konteynere monte etmek için.

Bu seçeneğin ardından son olarak uygulamanın çalışacağı görüntü gelir. NB: Bir görüntü oluştururken şunu belirtmeniz gerekir: CMD veya ENTRYPOINT!

Bundan sonra tam olarak ne olacak?

  • Kubernetes'te, belirtilen Dağıtım için kopya sayısı 0 olarak değiştirilecektir. Bunun yerine, yedek kapsayıcıyla yeni bir Dağıtım başlatılacaktır. backend.
  • Masaüstünde 2 konteyner başlatılacak: ilki Telepresence ile (Kubernetes'ten gelen/Kubernetes'e proxy istekleri gerçekleştirecek), ikincisi ise geliştirilmekte olan uygulamayla birlikte.
  • Uygulamayı konteynere çalıştırırsak dağıtım sırasında Helm tarafından aktarılan tüm ENV değişkenleri bizim için mevcut olacak ve tüm hizmetler de mevcut olacaktır. Geriye kalan tek şey, favori IDE'nizdeki kodu düzenlemek ve sonucun keyfini çıkarmak.
  • Çalışmanın sonunda Telepresence'ın çalıştığı terminali kapatmanız yeterlidir (oturumu Ctrl+C ile sonlandırın) - Docker konteynerleri masaüstünde duracak ve Kubernetes'te her şey başlangıç ​​​​durumuna dönecektir. Geriye kalan tek şey taahhüt etmek, MR'yi yayınlamak ve onu incelemeye/birleştirmeye/...'ye aktarmaktır (iş akışlarınıza bağlı olarak).

Uygulamayı bir Docker kapsayıcısında çalıştırmak istemiyorsak (örneğin, PHP'de değil Go'da geliştiriyorsak ve yine de yerel olarak oluşturuyorsak), Telepresence'ı başlatmak daha da basit olacaktır:

telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=true

Uygulama Kubernetes API'sine erişiyorsa, anahtarlar dizinini (https://www.telepresence.io/howto/volumes) bağlamanız gerekecektir. Linux için bir yardımcı program var kök:

proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash

Telepresence'ı seçenek olmadan başlattıktan sonra --docker-run tüm ortam değişkenleri mevcut terminalde mevcut olacaktır, dolayısıyla uygulamanın burada başlatılması gerekir.

NB: Örneğin PHP kullanırken, geliştirme için çeşitli op_cache, apc ve diğer hızlandırıcıları devre dışı bırakmayı unutmamalısınız - aksi takdirde kodu düzenlemek istenen sonuca yol açmaz.

sonuçlar

Kubernetes ile yerel kalkınma, bu platformun yaygınlaşmasıyla orantılı olarak çözümü de büyüyen bir sorun. Geliştiricilerden (müşterilerimizden) ilgili talepleri aldıktan sonra bunları mümkün olan ilk yöntemlerle çözmeye başladık, ancak bu uzun vadede kendini kanıtlayamadı. Neyse ki, bu sadece şimdi değil, sadece bizim için de açık hale geldi, bu yüzden dünyada daha uygun araçlar ortaya çıktı ve Telepresence bunların en ünlüsüdür (bu arada, ayrıca iskele Google'dan). Bunu kullanma konusundaki deneyimimiz henüz o kadar iyi değil, ancak şimdiden onu "mağazadaki meslektaşlarımıza" tavsiye etmemiz için neden veriyor - deneyin!

PS

K8'in ipuçları ve püf noktaları serisinden diğerleri:

Kaynak: habr.com

Yorum ekle