Menyesuaikan rencana migrasi untuk server Tomcat

Anda harus meninjau file rencana migrasi yang dihasilkan dari pembuatan migrasi. Sesuaikan file sebelum menjalankan migrasi. Detail rencana migrasi Anda digunakan untuk mengekstrak artefak penampung workload dari sumber.

Bagian ini menjelaskan konten migrasi dan jenis penyesuaian yang dapat Anda pertimbangkan sebelum menjalankan migrasi dan membuat artefak deployment.

Sebelum memulai

Topik ini mengasumsikan bahwa Anda telah membuat migrasi dan memiliki file rencana migrasi.

Mengedit rencana migrasi

Setelah menyalin sistem file dan menganalisisnya, Anda dapat menemukan rencana migrasi di direktori baru yang dibuat di jalur output yang ditentukan: ANALYSIS_OUTPUT_PATH/config.yaml.

Edit rencana migrasi sesuai kebutuhan dan simpan perubahan.

Tinjau detail rencana migrasi dan komentar panduan untuk menambahkan informasi sesuai kebutuhan. Secara khusus, pertimbangkan pengeditan di sekitar bagian berikut.

Menentukan image Docker

Dalam rencana migrasi, kita membuat tag image komunitas Docker berdasarkan versi Tomcat, versi Java, dan vendor Java.

• Versi Tomcat: versi Tomcat terdeteksi dan dikonversi ke versi utama (versi minor tidak didukung). Jika kita gagal mendeteksi versi Tomcat, baseImage.name akan berisi string kosong.
• Versi Java: versi Java bergantung pada parameter java-version. Nilai ini ditetapkan ke 11 secara default.
• Vendor Java: vendor Java ditetapkan ke konstanta: temurin.

Misalnya, tag image komunitas Docker yang dihasilkan untuk Tomcat versi 9.0, Java versi 11, dan vendor Java temurin adalah tomcat:9.0-jre11-temurin.

Dalam rencana migrasi, kolom baseImage.name mewakili tag image Docker yang digunakan sebagai dasar image container.

Versi Tomcat dan Java asli yang terdeteksi di VM sumber terdapat dalam discovery-report.yaml yang dihasilkan oleh penemuan awal.

Jika ingin mengubah image komunitas Docker, atau menyediakan image Docker Anda sendiri, Anda dapat mengubah baseImage.name dalam rencana migrasi menggunakan format berikut:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          baseImage:
            name: BASE_IMAGE_NAME

Ganti BASE_IMAGE_NAME dengan image Docker yang ingin Anda gunakan sebagai dasar image container.

Memperbarui jalur penginstalan Tomcat

Selama proses migrasi, jika image target Anda memiliki jalur CATALINA_HOME non-default, Anda dapat menentukan jalur CATALINA_HOME kustom. Edit kolom catalinaHome target langsung di rencana migrasi Anda:

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        baseImage:
          name: BASE_IMAGE_NAME
          catalinaHome: PATH

Ganti PATH dengan jalur penginstalan Tomcat.

Menyesuaikan pengguna dan grup

Selama proses migrasi, jika image target Anda berjalan dengan pengguna dan grup yang berbeda dari root:root, Anda dapat menentukan pengguna dan grup kustom yang akan digunakan untuk menjalankan aplikasi. Edit pengguna dan grup secara langsung dalam paket migrasi Anda:

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        userName: USERNAME
        groupName: GROUP_NAME

Ganti kode berikut:

• USERNAME: nama pengguna yang ingin Anda gunakan
• GROUP_NAME: nama grup yang ingin Anda gunakan

Mengonfigurasi SSL

Saat Anda membuat migrasi Tomcat baru, proses penemuan akan memindai server terhadap berbagai aplikasi yang ditemukan.

Setelah penemuan, kolom berikut akan otomatis diisi dalam rencana migrasi:

• excludeFiles: mencantumkan file dan direktori yang akan dikecualikan dari migrasi.

  Secara default, semua jalur dan sertifikat sensitif yang ditemukan selama penemuan otomatis ditambahkan ke kolom ini dan dikecualikan dari migrasi. Jika Anda menghapus jalur dari daftar ini, file atau direktori akan diupload ke image container. Untuk mengecualikan file atau direktori dari image penampung, tambahkan jalur ke daftar ini.

• sensitiveDataPaths: mencantumkan semua jalur dan sertifikat sensitif yang ditemukan oleh proses penemuan.

  Untuk mengupload sertifikat ke repositori, tetapkan kolom includeSensitiveData ke true:

  # Sensitive data which will be filtered out of the container image.
  # If includeSensitiveData is set to true the sensitive data will be mounted on the container.
  
  includeSensitiveData: true
  tomcatServers:
  - name: latest
    catalinaBase: /opt/tomcat/latest
    catalinaHome: /opt/tomcat/latest
    # Exclude files from migration.
    excludeFiles:
    - /usr/local/ssl/server.pem
    - /usr/home/tomcat/keystore
    - /usr/home/tomcat/truststore
    images:
    - name: tomcat-latest
      ...
      # If set to true, sensitive data specified in sensitiveDataPaths will be uploaded to the artifacts repository.
      sensitiveDataPaths:
      - /usr/local/ssl/server.pem
      - /usr/home/tomcat/keystore
      - /usr/home/tomcat/truststore
  

  Setelah migrasi selesai, secret ditambahkan ke file secret secrets.yaml di repositori artefak.

Catatan: Selain file dan direktori yang tercantum di kolom excludeFiles, direktori /bin, /lib, /temp, /logs, dan /work juga dikecualikan dari image penampung.

Logging webapp

Migrate to Containers mendukung logging dengan log4j v2, logback, dan log4j v1.x yang berada di CATALINA_HOME.

Penting: Jalur di luar CATALINA_HOME tidak didukung.

Migrate to Containers membuat file arsip tambahan dengan konfigurasi log yang diubah dan mengonversi semua appender jenis file menjadi appender konsol. Anda dapat menggunakan konten arsip ini sebagai referensi untuk mengaktifkan pengumpulan log dan streaming ke solusi pengumpulan log (seperti Google Cloud Logging).

Catatan: Saat bermigrasi ke image container, Migrate to Containers memfilter direktori logs dari server Tomcat untuk menghapus log lama.

Alokasi memori

Selama proses migrasi, Anda dapat menentukan batas memori aplikasi yang dimigrasikan ke setiap penampung. Edit batas memori langsung di rencana migrasi Anda menggunakan format berikut:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limit: 2048M
              requests: 1280M

Nilai yang direkomendasikan untuk limit adalah 200% dari Xmx, yang merupakan ukuran heap Java maksimum. Nilai yang direkomendasikan untuk requests adalah 150% dari Xmx.

Untuk melihat nilai Xmx, jalankan perintah berikut:

ps aux | grep catalina

Jika batas memori telah ditentukan dalam rencana migrasi, Dockerfile yang dibuat bersama artefak lain setelah migrasi berhasil akan mencerminkan deklarasi Anda:

FROM tomcat:8.5-jdk11-openjdk

# Add JVM environment variables for tomcat
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50.0 -XX:InitialRAMPercentage=50.0 -XX:+UseContainerSupport <additional variables>"

Ini menentukan ukuran awal dan maksimum menjadi 50% dari nilai batas. Hal ini memungkinkan ukuran alokasi heap Java Tomcat berubah sesuai dengan perubahan apa pun pada batas memori pod.

Catatan: Jika kolom catalinaOpts berisi variabel -Xms/InitialRAMPrecentage/InitialRAMFraction/InitialHeapSize, variabel lingkungan InitialRAMPercentage=50 tidak ditetapkan.

Menetapkan variabel lingkungan Tomcat

Jika ingin menetapkan CATALINA_OPTS di Dockerfile yang dibuat bersama artefak lain setelah migrasi berhasil, Anda dapat menambahkannya terlebih dahulu ke kolom catalinaOpts dalam rencana migrasi. Contoh berikut menunjukkan kolom catalinaOpts yang diperbarui:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xss10M"

Migrate to Containers mengurai data catalinaOpts ke Dockerfile Anda. Contoh berikut menunjukkan output penguraian:

FROM 8.5-jdk11-openjdk-slim

## setenv.sh script detected.
## Modify env variables on the script and add definitions to the migrated
## tomcat server, if needed (less recommended than adding env variables directly
## to CATALINA_OPTS) by uncomment the line below
#ADD --chown=root:root setenv.sh /usr/local/tomcat/bin/setenv.sh

# Add JVM environment variables for the tomcat server
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50.0 -XX:InitialRAMPercentage=50.0 -Xss10M"

Anda juga dapat menetapkan variabel lingkungan Tomcat menggunakan skrip setenv.sh, yang terletak di folder /bin di server Tomcat Anda. Untuk mengetahui informasi selengkapnya tentang variabel lingkungan Tomcat, lihat dokumentasi Tomcat.

Jika memilih untuk menggunakan setenv.sh untuk menetapkan variabel lingkungan Tomcat, Anda harus mengedit Dockerfile.

Catatan: Jika Anda menetapkan -Xmx, -XX:MaxRAMPercentage akan ditimpa. Jika Anda menetapkan -Xms, -XX:InitialRAMPercentage akan ditimpa.

Catatan: Migrate to Containers dan GKE tidak mengevaluasi konten setenv.sh. Oleh karena itu, sebaiknya tambahkan variabel lingkungan Tomcat Anda ke CATALINA_OPTS secara langsung.

Menetapkan pemeriksaan kesehatan Tomcat

Anda dapat memantau periode nonaktif dan status siap penampung terkelola dengan menentukan probe dalam rencana migrasi server web Tomcat. Pemantauan probe kesehatan dapat membantu mengurangi periode nonaktif container yang dimigrasikan dan memberikan pemantauan yang lebih baik.

Status kondisi yang tidak diketahui dapat menyebabkan penurunan ketersediaan, pemantauan ketersediaan positif palsu, dan potensi kehilangan data. Tanpa pemeriksaan kondisi, kubelet hanya dapat mengasumsikan kondisi container dan mungkin mengirim traffic ke instance container yang belum siap. Hal ini dapat menyebabkan hilangnya traffic. Kubelet mungkin juga tidak mendeteksi penampung yang dalam status beku dan tidak memulai ulang penampung tersebut.

Pemeriksaan kesehatan berfungsi dengan menjalankan pernyataan skrip kecil saat penampung dimulai. Skrip memeriksa kondisi yang berhasil, yang ditentukan oleh jenis probe yang digunakan, setiap periode. Periode ditentukan dalam rencana migrasi oleh kolom periodSeconds. Anda dapat menjalankan atau menentukan skrip ini secara manual.

Untuk mempelajari pemeriksaan kubelet lebih lanjut, lihat Mengonfigurasi Pemeriksaan Keaktifan, Kesiapan, dan Proses Mulai Sistem dalam dokumentasi Kubernetes.

Ada dua jenis probe yang tersedia untuk dikonfigurasi, kedua probe tersebut adalah probe-v1-core yang ditentukan dalam referensi probe-v1-core dan memiliki fungsi yang sama dengan kolom yang sesuai dari container-v1-core

• Pemeriksaan keaktifan: Pemeriksaan keaktifan digunakan untuk mengetahui kapan harus memulai ulang container.
  Catatan: Jika proses dalam penampung dapat mengalami error dengan sendirinya saat mengalami masalah, atau menjadi tidak responsif, Anda tidak perlu pemeriksaan keaktifan. Kublet otomatis melakukan tindakan yang benar sesuai dengan restartPolicy Pod.
• Pemeriksaan kesiapan: Pemeriksaan kesiapan digunakan untuk mengetahui kapan penampung siap untuk mulai menerima traffic. Untuk mulai mengirim traffic ke Pod hanya saat pemeriksaan berhasil, tentukan pemeriksaan kesiapan. Pemeriksaan kesiapan mungkin bertindak serupa dengan pemeriksaan keaktifan, tetapi pemeriksaan kesiapan dalam spesifikasi menunjukkan bahwa Pod dimulai tanpa menerima traffic apa pun dan hanya mulai menerima traffic setelah pemeriksaan berhasil.

Setelah penemuan, konfigurasi probe ditambahkan ke rencana migrasi. Probe dapat digunakan dalam konfigurasi defaultnya seperti yang ditunjukkan dalam contoh berikut. Untuk menonaktifkan probe, hapus bagian probes dari file YAML.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
        tcpSocket:
          port: 8080
      readinessProbe:
        tcpSocket:
          port: 8080

Anda dapat mengubah rencana migrasi ini untuk menggunakan endpoint HTTP Tomcat yang ada.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
       httpGet:
          path: /healthz
          port: 8080
          httpHeaders:
          - name: Custom-Header
            value: Awesome
        initialDelaySeconds: 3
        periodSeconds: 3
      readinessProbe:
        httpGet:
        tcpSocket:
          port: 8080

Ada empat cara standar untuk memeriksa penampung menggunakan probe. Setiap probe harus menentukan salah satu dari empat mekanisme ini:

• exec: Menjalankan perintah yang ditentukan di dalam penampung. Eksekusi dianggap berhasil jika kode status keluar adalah 0.
• grpc: Melakukan panggilan prosedur jarak jauh menggunakan `gRPC`. Probe `gRPC` adalah fitur alfa.
• httpGet: Melakukan permintaan GET HTTP terhadap alamat IP Pod di port dan jalur yang ditentukan. Permintaan dianggap berhasil jika kode status lebih besar dari atau sama dengan 200 dan kurang dari 400.
• tcpSocket: Melakukan pemeriksaan TCP terhadap alamat IP Pod di port yang ditentukan. Diagnostik dianggap berhasil jika port terbuka.

Secara default, rencana migrasi mengaktifkan metode pemeriksaan tcpSocket. Gunakan konfigurasi manual rencana migrasi Anda untuk menggunakan metode pemeriksaan yang berbeda. Anda juga dapat menentukan perintah dan skrip kustom melalui rencana migrasi.

Untuk menambahkan dependensi eksternal untuk probe kesiapan, saat menggunakan probe keaktifan default, tentukan probe kesiapan exec dan skrip yang mengimplementasikan logika.

Memverifikasi konfigurasi clustering Tomcat

Pengelompokan Tomcat digunakan untuk mereplikasi informasi sesi di semua node Tomcat, yang memungkinkan Anda memanggil server aplikasi backend dan tidak kehilangan informasi sesi klien. Untuk mempelajari konfigurasi pengelompokan lebih lanjut, lihat Cara Kerja Replikasi Sesi/Pengelompokan dalam dokumentasi Tomcat.

Class pengelompokan Tomcat disebut SimpleTcpListener, yang menggunakan pesan heartbeat multicast untuk penemuan peer. Lingkungan cloud tidak mendukung multicast, sehingga Anda harus mengubah konfigurasi pengelompokan atau menghapusnya, jika memungkinkan.

Saat dikonfigurasi untuk menjalankan dan mempertahankan sesi persisten ke server Tomcat backend, load balancer dapat menggunakan properti jvmRoute yang dikonfigurasi dalam konfigurasi Engine server.xml.

Jika lingkungan sumber Anda menggunakan konfigurasi pengelompokan yang tidak didukung, ubah file server.xml untuk menonaktifkan konfigurasi, atau gunakan konfigurasi yang didukung.

• Tomcat v8.5 atau yang lebih baru: Pengelompokan harus dinonaktifkan di Tomcat versi 8.5. Untuk menonaktifkan pengelompokan, Anda harus mengomentari bagian <Cluster … /> di server.xml.

• Tomcat v9 atau yang lebih baru: Di Tomcat versi 9 atau yang lebih baru, Anda dapat mengaktifkan class Cluster menggunakan KubernetesMembershipService. KubernetesMembershipService adalah class khusus Kubernetes, yang menggunakan Kubernetes API untuk penemuan peer.

  • Penyedia Kubernetes: Berikut adalah contoh konfigurasi untuk penyedia Kubernetes:

    <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
    <Channel className="org.apache.catalina.tribes.group.GroupChannel">
    <Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider"/>
    </Channel>
    </Cluster>
    

  • Penyedia DNS: Gunakan DNSMembershipProvider untuk menggunakan DNS API untuk penemuan peer. Berikut adalah contoh konfigurasi untuk penyedia DNS:

    <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
    <Channel className="org.apache.catalina.tribes.group.GroupChannel">
    <Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.DNSMembershipProvider"/>
    </Channel>
    </Cluster>
    

  • jvmRoute: Jika load balancer Anda mengandalkan nilai jvmRoute, nilai tersebut harus diubah dari statis menjadi menggunakan nama POD. Tindakan ini akan mengonfigurasi Tomcat untuk menambahkan akhiran ke cookie sesi dengan nama POD. Ini dapat digunakan oleh load balancer frontend untuk mengarahkan traffic ke POD Tomcat yang benar. Ubah nilai dalam file server.xml untuk menggunakan hal berikut:

    <Engine name="Catalina" defaultHost="localhost" jvmRoute="${HOSTNAME}">
    

Memverifikasi konfigurasi proxy Tomcat

Jika Tomcat dikonfigurasi untuk berjalan di belakang reverse proxy, atau menggunakan beberapa setelan konfigurasi proxy di bagian Connector dari server.xml, Anda harus memverifikasi bahwa konfigurasi proxy yang sama masih berlaku setelah dimigrasikan untuk berjalan di Kubernetes.

Untuk menjalankan aplikasi Tomcat dalam penampung yang berfungsi, pilih salah satu perubahan konfigurasi berikut pada konfigurasi proxy terbalik:

• Menonaktifkan konfigurasi proxy: Jika aplikasi yang dimigrasikan tidak lagi berjalan di balik reverse proxy, Anda dapat menonaktifkan konfigurasi proxy dengan menghapus proxyName dan proxyPort dari konfigurasi konektor.
• Memigrasikan proxy: Memigrasikan VM proxy dan mempertahankan semua konfigurasi Tomcat yang ada.

• Mengonfigurasi Ingress untuk mengganti reverse proxy: Jika tidak ada logika kustom atau canggih yang telah diterapkan untuk reverse proxy, Anda dapat mengonfigurasi resource Ingress untuk mengekspos aplikasi Tomcat yang dimigrasikan. Proses ini menggunakan FQDN yang sama dengan yang digunakan sebelum migrasi. Untuk mengonfigurasi Ingress, Anda harus memverifikasi bahwa Layanan Kubernetes Tomcat Anda adalah type: Nodeport. Berikut adalah contoh konfigurasi Ingress:

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-tomcat-ingress
  spec:
    rules:
    - host: APP_DOMAIN
      http:
        paths:
        - pathType: ImplementationSpecific
          backend:
            service:
              name: my-tomcat-service
              port:
                name: my-tomcat-port
  

  Catatan: Jika reverse proxy digunakan untuk memindahkan traffic SSL, sebaiknya Anda mengonfigurasi Ingress menggunakan sertifikat SSL. Untuk mempelajari lebih lanjut cara menggunakan sertifikat SSL, lihat Menggunakan beberapa sertifikat SSL di load balancing HTTPS dengan Ingress.

• Mengonfigurasi Cloud Service Mesh dengan Cloud Load Balancing: Jika menggunakan GKE Enterprise, Anda dapat memilih untuk mengekspos aplikasi menggunakan Cloud Service Mesh. Untuk mempelajari lebih lanjut cara mengekspos aplikasi mesh layanan, lihat Dari edge ke mesh: Mengekspos aplikasi mesh layanan melalui GKE Ingress.

Memverifikasi konfigurasi proxy Java

Saat bermigrasi ke penampung, Anda harus memverifikasi ketersediaan server proxy di lingkungan baru. Jika server proxy tidak tersedia, pilih salah satu perubahan konfigurasi berikut pada proxy:

• Nonaktifkan proxy: Jika proxy asli tidak lagi digunakan, nonaktifkan konfigurasi proxy. Hapus semua setelan proxy dari skrip setenv.sh, atau dari file konfigurasi tempat setelan tersebut dikelola di server Tomcat Anda.
• Mengubah setelan proxy: Jika lingkungan Kubernetes Anda menggunakan proxy egress yang berbeda, Anda dapat mengubah setelan proxy di setenv.sh, atau file lainnya, untuk mengarah ke proxy baru.

Langkah selanjutnya

• Pelajari cara menjalankan migrasi.