Hatalar ; Developer ve DevOps ekipleri arasında bir döngü problemidir. Artık monolitik bir yapı kalmadığını düşünürsek :) Developer kodu pipeline sürecine ilettikten ve sonra kodun çalışmadığı Developer veya Devops kontrollerinde anlaşılır. Birlikte problemi loglama ( Örneğin; Elastic / Kibana ) gibi mekanizmalarından araştırken ortaya çıkacak cevap bellidir ; “Local makinemde çalışıyor !”.
Peki sorun nerede ? Çalıştığınız ortamlar Container ( Örneğin ; Kubernetes ) platformlarda, birbirinden bağımsız mikroservis mimarisi ve frontend / backend katmanlarından oluşuyorsa daha karmaşık bir hal alacaktır. Local ortamlar ile runtime container ortamların bire bir aynı ( Version, JRE, DB gibi ) olması mümkün müdür ? Bu konu ile ilgili bir ilerleyen yazılarımda Backing Services ve Dev/Prod Parity başlıkları ortamların tekilleştirilmesi adına bir yazı yazacağım. Tabi ki mümkün olamayacak , olmayabilir.
Konumuza dönelim ve çözüm yöntemini uygulayalım :)
1) Debug etmek istediğiniz uygulamanızın Kubernetes üzerinde çalıştığını ve Dockerfile sahip olduğunuzu varsayıyorum.
Dockerfile:
FROM anapsix/alpine-java:8_server-jre_unlimited
FROM openjdk:8-jdk-alpine
ADD target/*.jar app.jar
ENV PROFILE=Dev
CMD["java", "-Dspring.profiles.active=${PROFILE}", "-agentlib:jdwp=transport=dt_socket,address=5005,server=y,suspend=n","-Djava.security.egd=file:/dev/./urandom","-Xms2g","-Xmx8g","-jar","app.jar"]
Örnek Dockerfile içerisindeki “-agentlib:jdwp=transport=dt_socket,address=5005,server=y,suspend=n”,”-Djava.security.egd=file:/dev/./urandom”,”-Xms2g”,”-Xmx8g” debug etmemize yarayacak parametrelerin detaylarını bilgi edinmeniz açısından aşağıda paylaşıyorum. Ayrıca çalışmamız da 5005 numaralı portun debug JAVA hata ayıklayıcısı olacağına dikkat edelim.
Jdwp: Bağlantı ayrıntılarını belirtir:
Transport: Uygulama ve hata ayıklayıcı arasındaki aktarımı yapılandırır. İki değeri olabilir: “dt_socket” veya “shmem”. “Dt_socket” soket arayüzüne talimat verir. “Shmem” uygulaması, hem uygulama hem de hata ayıklayıcı aynı makinede çalışırken yararlı olan paylaşılan bellek bölgesi üzerinden uygulama ve hata ayıklayıcı etkileşimini bildirir.
Address: Uzaktan hata ayıklama için uygulama tarafından açılacak bağlantı noktası.
Suspend: İki değeri olabilir. “Y”, herhangi bir uzak hata ayıklayıcı uygulamaya bağlanana kadar uygulamanın askıya alınacağı anlamına gelir. “N”, uygulamaya uzak bir hata ayıklayıcı bağlı olmasa bile uygulamanın askıya alınmayacağı anlamına gelir.
Spring Boot uygulamamız için hazırladığımız yukarıdaki Dockerfile kodunuza ekleyerek veya yine yukarıda belirttiğim parametreyi mevcut Dockerfile ‘ınıza ekleyerek build alabilirsiniz. Artık uygulamamızın debug modunu aktif hale getirmiş bulunuyoruz.
2) Sıradaki işlem ; mikro servisimizin debug portunu kubernetes üzerinde çalışmasına yarayan tanımı eklemek olacaktır. Aşağıda gördüğünüz gibi mikro servisimizin service yaml içerisinde “ports” kısmına debug portu ekliyorum.
Resim-1
3) Spring Boot uygulamamızın build ( Dockerfile) sürecindeki ve deployment sürecindeki ( yaml ) eklemeleride tamamladığımıza göre uygulamamızı Kubernetes ortamına deploy edebiliriz. Deploy sonrasında ilgili deployment’a ait service çıktısı aşağıdaki gibi olmalıdır.
kubectl get svc -o wide
Resim-2
Detay:
Resim-3
4) Son olarak uygulamanıza IntelliJ Idea dan debug mode ile bağlanarak, anlık hataları ayıklayabilmek istiyorsanız aşağıda resimdeki işlemi yapmanız yeterli olacak.
Resim-4
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: Container, Debugging, Java, Kubernetes, Remote Debug, Spring