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 digunakan untuk mengekstrak artefak penampung beban kerja 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 paket migrasi

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

Edit rencana migrasi seperlunya dan simpan perubahannya.

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

Menentukan image Docker

Dalam rencana migrasi, kami 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 gagal mendeteksi versi Tomcat, baseImage.name akan berisi string kosong.
Versi Java: versi Java bergantung pada parameter java-version. Atribut ini disetel ke 11 secara default.
Vendor Java: vendor Java disetel ke konstanta: temurin.

Misalnya, tag image komunitas Docker yang dihasilkan untuk Tomcat versi 9.0, Java versi 11, dan temurin vendor Java 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 pada VM sumber terdapat dalam discovery-report.yaml yang dihasilkan oleh penemuan awal.

Jika ingin mengubah image komunitas Docker, atau menyediakan image Docker 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 memiliki jalur CATALINA_HOME non-default, Anda dapat menentukan jalur CATALINA_HOME kustom. Edit kolom catalinaHome target secara 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.

Sesuaikan pengguna dan grup

Selama proses migrasi, jika image target dijalankan dengan pengguna dan grup yang berbeda dengan root:root, Anda dapat menentukan pengguna dan grup kustom tempat aplikasi dijalankan. Edit pengguna dan grup secara langsung dalam rencana 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 memindai server untuk mendeteksi berbagai aplikasi yang ditemukan.

Setelah ditemukan, kolom berikut akan otomatis diisi dalam paket migrasi:

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

Secara default, semua jalur dan sertifikat sensitif yang terletak 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 container, tambahkan jalur ke daftar ini.

sensitiveDataPaths: mencantumkan semua jalur dan sertifikat sensitif yang berada 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 akan ditambahkan ke file rahasia secrets.yaml di repositori artefak.

Logging aplikasi web

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

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

Alokasi memori

Selama proses migrasi, Anda dapat menentukan batas memori aplikasi yang dimigrasikan ke container individual. Edit batas memori secara langsung dalam paket 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 Anda, Dockerfile yang dihasilkan 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 50% dari nilai batas. Hal ini memungkinkan ukuran alokasi heap Tomcat Java berubah sesuai dengan perubahan apa pun dengan batas memori pod.

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 Anda. Contoh berikut menunjukkan kolom catalinaOpts yang diperbarui:

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

Migrate to Containers akan mengurai data catalinaOpts Anda ke Dockerfile. 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 pada server Tomcat Anda. Untuk mengetahui informasi selengkapnya tentang variabel lingkungan Tomcat, lihat dokumentasi Tomcat.

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

Setel pemeriksaan kesehatan Tomcat

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

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

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

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

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

Pemeriksaan kehidupan: Pemeriksaan keaktifan digunakan untuk mengetahui kapan harus memulai ulang container.

Catatan: Jika proses dalam penampung Anda dapat error dengan sendirinya saat mengalami masalah, atau menjadi tidak sehat, Anda tidak memerlukan pemeriksaan keaktifan. Kubelet secara 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 ketika pemeriksaan berhasil, tentukan kesiapan. Pemeriksaan kesiapan mungkin bertindak mirip dengan pemeriksaan keaktifan, tetapi pemeriksaan kesiapan dalam spesifikasi menunjukkan bahwa Pod dimulai tanpa menerima traffic dan hanya mulai menerima traffic setelah pemeriksaan berhasil.

Setelah ditemukan, konfigurasi pemeriksaan ditambahkan ke paket migrasi. Probe dapat digunakan dalam konfigurasi default seperti yang ditunjukkan pada contoh berikut. Untuk menonaktifkan pemeriksaan, 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 paket migrasi ini untuk menggunakan endpoint HTTP Tomcat yang sudah 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 yang telah ditentukan untuk memeriksa container menggunakan probe. Setiap pemeriksaan harus menentukan dengan tepat salah satu dari empat mekanisme ini:

exec: Mengeksekusi perintah yang ditentukan di dalam container. Eksekusi dianggap berhasil jika kode status keluar adalah 0.
grpc: Melakukan panggilan prosedur jarak jauh menggunakan `gRPC`. Pemeriksaan `gRPC` adalah fitur alfa.
httpGet: Menjalankan permintaan GET HTTP terhadap alamat IP Pod di port dan jalur yang ditentukan. Permintaan dianggap berhasil jika kode statusnya 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 skrip dan perintah kustom melalui rencana migrasi.

Guna menambahkan dependensi eksternal untuk pemeriksaan kesiapan, saat menggunakan pemeriksaan keaktifan default, tentukan pemeriksaan kesiapan eksekutif dan skrip yang menerapkan logika.

Memverifikasi konfigurasi pengelompokan Tomcat

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

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

Saat dikonfigurasi untuk menjalankan dan mempertahankan sesi melekat ke server Tomcat backend, load balancer dapat menggunakan properti jvmRoute yang dikonfigurasi di 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 perlu memberi komentar pada 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 pembanding.
- Penyedia Kubernetes: Berikut ini 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 API DNS agar dapat ditemukan oleh pembanding. 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 proxy terbalik, atau menggunakan beberapa setelan konfigurasi proxy di bagian Connector pada server.xml, Anda harus memverifikasi bahwa konfigurasi proxy yang sama masih berlaku setelah dimigrasikan untuk dijalankan di Kubernetes.

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

Nonaktifkan konfigurasi proxy: Jika aplikasi yang dimigrasikan tidak lagi berjalan di belakang reverse proxy, Anda dapat menonaktifkan konfigurasi proxy dengan menghapus proxyName dan proxyPort dari konfigurasi konektor.
Migrasikan proxy: Migrasikan VM proxy dan pertahankan semua konfigurasi Tomcat yang ada.
Mengonfigurasi Ingress untuk mengganti reverse proxy: Jika tidak ada logika kustom atau canggih yang 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, Anda mungkin ingin mengonfigurasi Ingress menggunakan sertifikat SSL. Untuk mempelajari lebih lanjut cara menggunakan sertifikat SSL, lihat Menggunakan beberapa sertifikat SSL dalam load balancing HTTPS dengan Ingress.
Mengonfigurasi Anthos Service Mesh dengan Cloud Load Balancing: Jika menggunakan GKE Enterprise, Anda dapat memilih untuk mengekspos aplikasi menggunakan Anthos Service Mesh. Untuk mempelajari lebih lanjut cara mengekspos aplikasi mesh layanan, lihat Dari tepi ke mesh: Mengekspos aplikasi mesh layanan melalui GKE Ingress.

Memverifikasi konfigurasi proxy Java

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

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.
Ubah setelan proxy: Jika lingkungan Kubernetes Anda menggunakan proxy keluar yang berbeda, Anda dapat mengubah setelan proxy di setenv.sh, atau file lainnya, agar mengarah ke proxy baru.

Langkah selanjutnya

Pelajari cara menjalankan migrasi.