Bermigrasi dari Memcache App Engine ke Cloud Memorystore (Modul 13)

1. Ringkasan

Serangkaian codelab Serverless Migration Station (tutorial praktik mandiri) dan video terkait bertujuan untuk membantu developer serverless Google Cloud memodernisasi aplikasi mereka dengan memandu mereka melalui satu atau beberapa migrasi, terutama beralih dari layanan lama. Dengan melakukannya, aplikasi Anda akan lebih portabel dan Anda akan memiliki lebih banyak opsi dan fleksibilitas, sehingga Anda dapat berintegrasi dengan dan mengakses berbagai produk Cloud serta mengupgrade ke rilis bahasa yang lebih baru dengan lebih mudah. Meskipun awalnya berfokus pada pengguna Cloud paling awal, terutama developer App Engine (lingkungan standar), seri ini cukup luas untuk mencakup platform serverless lainnya seperti Cloud Functions dan Cloud Run, atau di tempat lain jika berlaku.

Tujuan codelab ini adalah untuk menunjukkan kepada developer App Engine Python 2 cara bermigrasi dari Memcache App Engine ke Cloud Memorystore (untuk Redis). Ada juga migrasi implisit dari App Engine ndb ke Cloud NDB, tetapi hal ini terutama dibahas dalam codelab Modul 2; lihat codelab tersebut untuk mengetahui informasi langkah demi langkah selengkapnya.

Anda akan mempelajari cara

Menyiapkan instance Cloud Memorystore (dari Cloud Console atau alat gcloud)
Siapkan konektor Akses VPC Serverless Cloud (dari Konsol Cloud atau alat gcloud)
Melakukan migrasi dari Memcache App Engine ke Cloud Memorystore
Mengimplementasikan penyimpanan ke cache dengan Cloud Memorystore di aplikasi contoh
Migrasikan dari ndb App Engine ke Cloud NDB

Yang Anda butuhkan

Project Google Cloud dengan akun penagihan aktif (ini bukan codelab gratis)
Keterampilan Python dasar
Pengetahuan perintah Linux umum yang berfungsi
Pengetahuan dasar tentang mengembangkan dan men-deploy aplikasi App Engine
Aplikasi App Engine Modul 12 yang berfungsi (selesaikan codelab Modul 12 [direkomendasikan] atau salin aplikasi Modul 12 dari repo)

Survei

Bagaimana Anda akan menggunakan tutorial ini?

Hanya membacanya

Membacanya dan menyelesaikan latihan

Bagaimana penilaian Anda terhadap pengalaman dengan Python?

Pemula

Menengah

Mahir

Bagaimana penilaian Anda terhadap pengalaman menggunakan layanan Google Cloud?

Pemula

Menengah

Mahir

2. Latar belakang

Codelab ini menunjukkan cara memigrasikan aplikasi contoh dari Memcache App Engine (dan NDB) ke Cloud Memorystore (dan Cloud NDB). Proses ini melibatkan penggantian dependensi pada layanan paket App Engine, sehingga aplikasi Anda menjadi lebih portabel. Anda dapat memilih untuk tetap menggunakan App Engine atau mempertimbangkan untuk beralih ke salah satu alternatif yang dijelaskan sebelumnya.

Migrasi ini memerlukan lebih banyak upaya dibandingkan dengan migrasi lainnya dalam seri ini. Pengganti yang direkomendasikan untuk Memcache App Engine adalah Cloud Memorystore, layanan caching berbasis cloud yang terkelola sepenuhnya. Memorystore mendukung sepasang mesin cache open source populer, Redis dan Memcached. Modul migrasi ini menggunakan Cloud Memorystore for Redis. Anda dapat mempelajari lebih lanjut di Ringkasan Memorystore dan Redis.

Karena Memorystore memerlukan server yang berjalan, Cloud VPC juga diperlukan. Secara khusus, konektor Akses VPC Serverless harus dibuat agar aplikasi App Engine dapat terhubung ke instance Memorystore melalui alamat IP pribadinya. Setelah menyelesaikan latihan ini, Anda akan memperbarui aplikasi sehingga meskipun berperilaku seperti sebelumnya, Cloud Memorystore akan menjadi layanan caching, menggantikan layanan Memcache App Engine.

Tutorial ini dimulai dengan aplikasi contoh Modul 12 di Python 2, diikuti dengan upgrade kecil tambahan dan opsional ke Python 3. Jika Anda sudah memahami cara mengakses layanan paket App Engine dari Python 3 melalui SDK App Engine Python 3, Anda dapat memulai dengan aplikasi contoh Modul 12 versi Python 3. Tindakan ini akan mengharuskan penghapusan penggunaan SDK karena Memorystore bukan layanan paket App Engine. Mempelajari cara menggunakan Python 3 App Engine SDK berada di luar cakupan tutorial ini.

Tutorial ini menampilkan langkah-langkah utama berikut:

Penyiapan/prakerja
Menyiapkan layanan caching
Update file konfigurasi
Memperbarui aplikasi utama

3. Penyiapan/prakerja

Siapkan project Cloud

Sebaiknya gunakan kembali project yang sama dengan yang Anda gunakan untuk menyelesaikan codelab Modul 12. Atau, Anda dapat membuat project baru atau menggunakan kembali project lain yang sudah ada. Setiap codelab dalam seri ini memiliki "START" (kode dasar untuk memulai) dan "FINISH" (aplikasi yang dimigrasikan). Kode FINISH disediakan agar Anda dapat membandingkan solusi Anda dengan solusi kami jika Anda mengalami masalah. Anda selalu dapat membatalkan perubahan untuk MEMULAI lagi jika terjadi kesalahan. Pos pemeriksaan ini dirancang untuk memastikan Anda berhasil mempelajari cara melakukan migrasi.

Project Cloud mana pun yang Anda gunakan, pastikan project tersebut memiliki akun penagihan yang aktif. Pastikan juga bahwa App Engine diaktifkan. Tinjau dan pastikan Anda memahami implikasi biaya umum dalam menyelesaikan tutorial ini. Namun, tidak seperti codelab lain dalam seri ini, codelab ini menggunakan resource Cloud yang tidak memiliki paket gratis, sehingga beberapa biaya akan dikenakan untuk menyelesaikan latihan ini. Informasi biaya yang lebih spesifik akan diberikan bersama dengan rekomendasi untuk mengurangi penggunaan, termasuk petunjuk di bagian akhir tentang cara melepaskan resource untuk meminimalkan biaya penagihan.

Dapatkan aplikasi contoh dasar pengukuran

Dari kode dasar Modul 12 yang kita MULAI, codelab ini akan memandu Anda melakukan migrasi langkah demi langkah. Setelah selesai, Anda akan mendapatkan aplikasi Modul 13 yang berfungsi dan sangat menyerupai kode di salah satu folder FINISH. Berikut referensi tersebut:

START: Aplikasi Python 2 Modul 12 (mod12) atau Python 3 (mod12b)
FINISH: Aplikasi Python 2 Modul 13 (mod13a) atau Python 3 (mod13b)
Seluruh repo migrasi (clone atau download ZIP)

Folder START harus berisi file berikut:

$ ls
README.md               app.yaml                main.py                 requirements.txt        templates

Jika Anda memulai dari versi Python 2, akan ada juga file appengine_config.py dan mungkin folder lib jika Anda telah menyelesaikan codelab Modul 12.

Deploy (ulang) aplikasi Modul 12

Langkah prakerja yang tersisa:

Biasakan kembali diri Anda dengan alat command-line gcloud (jika perlu)
Deploy (ulang) kode Modul 12 ke App Engine (jika perlu)

Pengguna Python 2 harus menghapus dan menginstal ulang folder lib dengan perintah berikut:

rm -rf ./lib; pip install -t lib -r requirements.txt

Sekarang semua orang (pengguna Python 2 dan 3) harus mengupload kode ke App Engine dengan perintah ini:

gcloud app deploy

Setelah berhasil di-deploy, konfirmasi bahwa tampilan dan fungsi aplikasi sama seperti aplikasi di Modul 12, yaitu aplikasi web yang melacak kunjungan, dan melakukan caching untuk pengguna yang sama selama satu jam:

Karena kunjungan terbaru di-cache, pemuatan ulang halaman akan dimuat dengan cukup cepat.

4. Menyiapkan layanan caching

Cloud Memorystore bukan layanan tanpa server. Instance diperlukan; dalam kasus ini, instance yang menjalankan Redis. Tidak seperti Memcache, Memorystore adalah produk Cloud mandiri dan tidak memiliki paket gratis, jadi pastikan untuk memeriksa informasi harga Memorystore for Redis sebelum melanjutkan. Untuk meminimalkan biaya latihan ini, sebaiknya gunakan jumlah minimum resource untuk beroperasi: tingkat layanan Basic dan kapasitas 1 GB.

Instance Memorystore berada di jaringan yang berbeda dengan aplikasi (instance) App Engine Anda, dan itulah sebabnya konektor Akses VPC Serverless harus dibuat agar App Engine dapat mengakses resource Memorystore Anda. Untuk meminimalkan biaya VPC, pilih jenis instance (f1-micro) dan jumlah instance paling sedikit yang akan diminta (sebaiknya minimum 2, maksimum 3). Lihat juga halaman informasi harga VPC.

Kami mengulangi rekomendasi ini untuk mengurangi biaya saat kami memandu Anda membuat setiap resource yang diperlukan. Selain itu, saat membuat resource Memorystore dan VPC di Konsol Cloud, Anda akan melihat kalkulator harga untuk setiap produk di pojok kanan atas, yang memberikan estimasi biaya bulanan (lihat ilustrasi di bawah). Nilai tersebut akan otomatis disesuaikan jika Anda mengubah opsi. Berikut perkiraan tampilan yang akan Anda lihat:

Kedua resource ini diperlukan, dan tidak masalah mana yang Anda buat terlebih dahulu. Jika Anda membuat instance Memorystore terlebih dahulu, aplikasi App Engine Anda tidak dapat menjangkaunya tanpa konektor VPC. Demikian pula, jika Anda membuat konektor VPC terlebih dahulu, tidak ada apa pun di jaringan VPC tersebut yang dapat dihubungi oleh aplikasi App Engine Anda. Dalam tutorial ini, Anda akan membuat instance Memorystore terlebih dahulu, lalu konektor VPC.

Setelah kedua resource online, Anda akan menambahkan informasi yang relevan ke app.yaml sehingga aplikasi Anda dapat mengakses cache. Anda juga dapat melihat panduan Python 2 atau Python 3 dalam dokumentasi resmi. Panduan penyiapan cache data di halaman migrasi Cloud NDB ( Python 2 atau Python 3) juga layak dirujuk.

Membuat instance Cloud Memorystore

Karena Cloud Memorystore tidak memiliki paket gratis, sebaiknya alokasikan jumlah resource paling sedikit untuk menyelesaikan codelab. Anda dapat meminimalkan biaya dengan menggunakan setelan berikut:

Pilih tingkat layanan terendah: Basic (default konsol: "Standard", default gcloud: "Basic").
Pilih jumlah penyimpanan terkecil: 1 GB (default konsol: 16 GB, default gcloud: 1 GB).
Biasanya, versi terbaru dari setiap software memerlukan jumlah resource terbesar, tetapi memilih versi terlama juga tidak disarankan. Versi kedua terbaru saat ini adalah versi Redis 5.0 (default konsol: 6.x)

Dengan mempertimbangkan setelan tersebut, bagian berikutnya akan memandu Anda membuat instance dari Konsol Cloud. Jika Anda lebih suka melakukannya dari command line, lewati bagian ini.

Dari Cloud Console

Buka halaman Cloud Memorystore di Konsol Cloud (Anda mungkin diminta untuk memberikan informasi penagihan). Jika Anda belum mengaktifkan Memorystore, Anda akan diminta untuk melakukannya:

Setelah mengaktifkannya (dan mungkin bersama dengan penagihan), Anda akan diarahkan ke dasbor Memorystore. Di sini Anda dapat melihat semua instance yang dibuat di project Anda. Project yang ditampilkan di bawah tidak memiliki baris, jadi itulah sebabnya Anda melihat "No rows to display". Untuk membuat instance Memorystore, klik Buat instance di bagian atas:

Halaman ini menampilkan formulir yang harus diisi dengan setelan yang diinginkan untuk membuat instance Memorystore:

Untuk menekan biaya tutorial ini dan aplikasi contohnya, ikuti rekomendasi yang dibahas sebelumnya. Setelah Anda menentukan pilihan, klik Buat. Proses pembuatan memerlukan waktu beberapa menit. Setelah selesai, salin alamat IP instance dan nomor port untuk ditambahkan ke app.yaml.

Dari command line

Meskipun pembuatan instance Memorystore dari Konsol Cloud memberikan informasi visual, beberapa pengguna lebih memilih command line. Pastikan Anda telah menginstal dan menginisialisasi gcloud sebelum melanjutkan.

Seperti halnya Cloud Console, Cloud Memorystore for Redis harus diaktifkan. Keluarkan perintah gcloud services enable redis.googleapis.com dan tunggu hingga selesai, seperti contoh ini:

$ gcloud services enable redis.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Jika layanan sudah diaktifkan, menjalankan perintah (lagi) tidak akan menimbulkan efek samping (negatif). Setelah layanan diaktifkan, mari buat instance Memorystore. Perintahnya terlihat seperti ini:

gcloud redis instances create NAME --redis-version VERSION \
    --region REGION --project PROJECT_ID

Pilih nama untuk instance Memorystore Anda; lab ini menggunakan "demo-ms" sebagai nama beserta project ID "my-project". Region aplikasi contoh ini adalah us-central1 (sama dengan us-central), tetapi Anda dapat menggunakan region yang lebih dekat dengan Anda jika latensi menjadi masalah. Anda harus memilih region yang sama dengan aplikasi App Engine Anda. Anda dapat memilih versi Redis yang diinginkan, tetapi kami menggunakan versi 5 seperti yang direkomendasikan sebelumnya. Dengan setelan tersebut, berikut perintah yang akan Anda jalankan (beserta output terkait):

$ gcloud redis instances create demo-ms --region us-central1 \
    --redis-version redis_5_0 --project my-project

Create request issued for: [demo-ms]
Waiting for operation [projects/my-project/locations/us-central1/operations/operation-xxxx] to complete...done.
Created instance [demo-ms].

Berbeda dengan default Konsol Cloud, gcloud menggunakan resource minimal secara default. Hasilnya, tingkat layanan maupun jumlah penyimpanan tidak diperlukan dalam perintah tersebut. Pembuatan instance Memorystore memerlukan waktu beberapa menit, dan setelah selesai, catat alamat IP dan nomor port instance karena akan segera ditambahkan ke app.yaml.

Konfirmasi instance dibuat

Dari Konsol Cloud atau command line

Baik Anda membuat instance dari Konsol Cloud maupun command line, Anda dapat mengonfirmasi bahwa instance tersedia dan siap digunakan dengan perintah ini: gcloud redis instances list --region REGION

Berikut adalah perintah untuk memeriksa instance di region us-central1 beserta output yang diharapkan yang menampilkan instance yang baru saja kita buat:

$ gcloud redis instances list --region us-central1
INSTANCE_NAME  VERSION    REGION       TIER   SIZE_GB  HOST         PORT  NETWORK  RESERVED_IP     STATUS  CREATE_TIME
demo-ms        REDIS_5_0  us-central1  BASIC  1        10.aa.bb.cc  6379  default  10.aa.bb.dd/29  READY   2022-01-28T09:24:45

Saat diminta informasi instance atau untuk mengonfigurasi aplikasi, pastikan untuk menggunakan HOST dan PORT (bukan RESERVED_IP). Dasbor Cloud Memorystore di Konsol Cloud kini akan menampilkan instance tersebut:

Dari virtual machine Compute Engine

Jika memiliki virtual machine (VM) Compute Engine, Anda juga dapat mengirim perintah langsung ke instance Memorystore dari VM untuk mengonfirmasi bahwa instance tersebut berfungsi. Perlu diketahui bahwa penggunaan VM mungkin memiliki biaya terkait yang terpisah dari resource yang sudah Anda gunakan.

Buat konektor Akses VPC Serverless

Seperti Cloud Memorystore, Anda dapat membuat konektor VPC Cloud serverless di Konsol Cloud atau di command line. Demikian pula, Cloud VPC tidak memiliki tingkatan gratis, jadi sebaiknya alokasikan resource dalam jumlah paling sedikit untuk menyelesaikan codelab demi meminimalkan biaya, dan hal ini dapat dicapai dengan setelan berikut:

Pilih jumlah maksimum instance terendah: 3 (konsol & default gcloud: 10)
Pilih jenis mesin dengan biaya terendah: f1-micro (default konsol: e2-micro, tanpa default gcloud)

Bagian berikutnya akan memandu Anda membuat konektor dari Konsol Cloud menggunakan setelan VPC Cloud di atas. Jika Anda lebih suka melakukannya dari command line, lanjutkan ke bagian berikutnya.

Dari Konsol Cloud

Buka halaman "Serverless VPC access" Cloud Networking di Konsol Cloud (Anda mungkin diminta untuk memberikan informasi penagihan). Jika belum mengaktifkan API, Anda akan diminta untuk melakukannya:

Setelah mengaktifkan API (dan mungkin bersama dengan penagihan), Anda akan diarahkan ke dasbor yang menampilkan semua konektor VPC yang dibuat. Project yang digunakan dalam screenshot di bawah tidak memiliki baris, jadi itulah sebabnya muncul tulisan "No rows to display". Di konsol Anda, klik Create Connector di bagian atas:

Isi formulir dengan setelan yang diinginkan:

Pilih setelan yang sesuai untuk aplikasi Anda sendiri. Untuk tutorial ini dan aplikasi contohnya dengan kebutuhan minimal, sebaiknya minimalkan biaya, jadi ikuti rekomendasi yang dibahas sebelumnya. Setelah Anda menentukan pilihan, klik Buat. Meminta konektor VPC akan memerlukan waktu beberapa menit hingga selesai.

Dari command line

Sebelum membuat konektor VPC, aktifkan terlebih dahulu Serverless VPC Access API. Anda akan melihat output yang serupa setelah mengeluarkan perintah berikut:

$ gcloud services enable vpcaccess.googleapis.com
Operation "operations/acf.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Setelah API diaktifkan, konektor VPC dibuat dengan perintah yang terlihat seperti ini:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
    --range 10.8.0.0/28 --region REGION --project PROJECT_ID

Pilih nama untuk konektor Anda serta alamat IP awal blok CIDR /28 yang tidak digunakan. Tutorial ini membuat asumsi berikut:

ID Project: my-project
Nama konektor VPC: demo-vpc
Instance min: 2 (default) dan instance maks: 3
Jenis instance: f1-micro
Region: us-central1
Blok CIDR IPv4: 10.8.0.0/28 (seperti yang direkomendasikan di konsol cloud)

Anda akan melihat output yang mirip dengan yang ada di bawah jika Anda menjalankan perintah berikut dengan asumsi di atas:

$ gcloud compute networks vpc-access connectors create demo-vpc \
    --max-instances 3 --range 10.8.0.0/28 --machine-type f1-micro \
    --region us-central1  --project my-project

Create request issued for: [demo-vpc]
Waiting for operation [projects/my-project/locations/us-central1/operations/xxx] to complete...done.
Created connector [demo-vpc].

Perintah di atas tidak menentukan nilai default, seperti instance minimum 2 dan jaringan bernama default. Pembuatan konektor VPC memerlukan waktu beberapa menit hingga selesai.

Mengonfirmasi konektor dibuat

Setelah proses selesai, jalankan perintah gcloud berikut, dengan asumsi instance berada di region us-central1, untuk mengonfirmasi bahwa instance telah dibuat dan siap digunakan:

$ gcloud compute networks vpc-access connectors list --region us-central1
CONNECTOR_ID  REGION       NETWORK  IP_CIDR_RANGE  SUBNET  SUBNET_PROJECT  MIN_THROUGHPUT  MAX_THROUGHPUT  STATE
demo-vpc      us-central1  default  10.8.0.0/28                            200             300             READY

Demikian pula, dasbor kini akan menampilkan konektor yang baru saja Anda buat:

Catat project ID Cloud, nama konektor VPC, dan region.

Setelah Anda membuat resource Cloud tambahan yang diperlukan, baik melalui command line maupun di konsol, sekarang saatnya memperbarui konfigurasi aplikasi untuk mendukung penggunaannya.

5. Update file konfigurasi

Langkah pertama adalah melakukan semua pembaruan yang diperlukan pada file konfigurasi. Membantu pengguna Python 2 melakukan migrasi adalah tujuan utama codelab ini, tetapi konten tersebut biasanya diikuti dengan informasi tentang porting lebih lanjut ke Python 3 di setiap bagian di bawah.

requirements.txt

Di bagian ini, kita akan menambahkan paket untuk mendukung Cloud Memorystore dan Cloud NDB. Untuk Cloud Memorystore for Redis, cukup gunakan klien Redis standar untuk Python (redis) karena tidak ada library klien Cloud Memorystore. Tambahkan redis dan google-cloud-ndb ke requirements.txt, bergabung dengan flask dari Modul 12:

flask
redis
google-cloud-ndb

File requirements.txt ini tidak memiliki nomor versi, yang berarti versi terbaru akan dipilih. Jika ada ketidakcocokan, tentukan nomor versi untuk mengunci versi yang berfungsi.

app.yaml

Bagian baru yang akan ditambahkan

Runtime Python 2 App Engine memerlukan paket pihak ketiga tertentu saat menggunakan Cloud API seperti Cloud NDB, yaitu grpcio dan setuptools. Pengguna Python 2 harus mencantumkan library bawaan seperti ini beserta versi yang tersedia di app.yaml. Jika Anda belum memiliki bagian libraries, buat bagian tersebut dan tambahkan kedua library seperti berikut:

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest

Saat memigrasikan aplikasi Anda, aplikasi tersebut mungkin sudah memiliki bagian libraries. Jika ada, dan grpcio serta setuptools tidak ada, cukup tambahkan ke bagian libraries yang sudah ada.

Selanjutnya, aplikasi contoh kita memerlukan informasi instance Cloud Memorystore dan konektor VPC, jadi tambahkan dua bagian baru berikut ke app.yaml, terlepas dari runtime Python yang Anda gunakan:

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Hanya itu saja update yang diperlukan. app.yaml yang diperbarui sekarang akan terlihat seperti ini:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Berikut adalah "sebelum dan sesudah" yang menggambarkan update yang harus Anda terapkan ke app.yaml:

*Perbedaan Python 3

Bagian ini bersifat opsional dan hanya jika Anda melakukan porting ke Python 3. Untuk melakukannya, ada sejumlah perubahan yang harus dilakukan pada konfigurasi Python 2 Anda. Lewati bagian ini jika Anda tidak melakukan upgrade saat ini.

threadsafe maupun api_version tidak digunakan untuk runtime Python 3, jadi hapus kedua setelan ini. Runtime App Engine terbaru tidak mendukung library pihak ketiga bawaan maupun penyalinan library non-bawaan. Satu-satunya persyaratan untuk paket pihak ketiga adalah mencantumkannya di requirements.txt. Akibatnya, seluruh bagian libraries dari app.yaml dapat dihapus.

Selanjutnya, runtime Python 3 memerlukan penggunaan framework web yang melakukan perutean sendiri, itulah sebabnya kami menunjukkan kepada developer cara bermigrasi dari webp2 ke Flask di Modul 1. Akibatnya, semua pengendali skrip harus diubah menjadi auto. Karena aplikasi ini tidak menayangkan file statis, "tidak ada gunanya" mencantumkan pengendali (karena semuanya auto), sehingga seluruh bagian handlers juga dapat dihapus. Akibatnya, app.yaml baru yang disingkat dan disesuaikan untuk Python 3 akan dipersingkat agar terlihat seperti ini:

runtime: python39

env_variables:
    REDIS_HOST: 'YOUR_REDIS_HOST'
    REDIS_PORT: 'YOUR_REDIS_PORT'

vpc_access_connector:
    name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR

Merangkum perbedaan dalam app.yaml saat melakukan porting ke Python 3:

Menghapus setelan threadsafe dan api_version
Menghapus bagian libraries
Hapus bagian handlers (atau hanya pengendali script jika aplikasi Anda menyajikan file statis)

Ganti nilai

Nilai di bagian baru untuk Memorystore dan konektor VPC hanyalah placeholder. Ganti nilai yang ditulis dengan huruf kapital tersebut (YOUR_REDIS_HOST, YOUR_REDIS_PORT, PROJECT_ID, REGION, CONNECTOR_NAME) dengan nilai yang disimpan saat Anda membuat resource tersebut sebelumnya. Terkait instance Memorystore Anda, pastikan untuk menggunakan HOST (bukan RESERVED_IP) dan PORT. Berikut adalah cara cepat menggunakan command line untuk mendapatkan HOST dan PORT dengan asumsi nama instance demo-ms dan REGION adalah us-central1:

$ gcloud redis instances describe demo-ms --region us-central1 \
    --format "value(host,port)"
10.251.161.51   6379

Jika alamat IP instance Redis contoh kita adalah 10.10.10.10 menggunakan port 6379 di project my-project yang berada di region us-central1 dengan nama konektor VPC demo-vpc, bagian-bagian ini di app.yaml akan terlihat seperti ini:

env_variables:
    REDIS_HOST: '10.10.10.10'
    REDIS_PORT: '6379'

vpc_access_connector:
    name: projects/my-project/locations/us-central1/connectors/demo-vpc

Membuat atau memperbarui appengine_config.py

Menambahkan dukungan untuk library bawaan pihak ketiga

Sama seperti yang kita lakukan dengan app.yaml sebelumnya, tambahkan penggunaan library grpcio dan setuptools. Ubah appengine_config.py untuk mendukung library pihak ketiga bawaan. Jika Anda merasa sudah pernah melihatnya, itu karena hal ini juga diperlukan di Modul 2 saat melakukan migrasi dari App Engine ndb ke Cloud NDB. Perubahan yang tepat yang diperlukan adalah menambahkan folder lib ke set kerja setuptools.pkg_resources:

*Perbedaan Python 3

Bagian ini bersifat opsional dan hanya jika Anda melakukan porting ke Python 3. Salah satu perubahan generasi kedua App Engine yang disambut baik adalah bahwa penyalinan (terkadang disebut "vendoring") paket pihak ketiga (non-bawaan) dan mereferensikan paket pihak ketiga bawaan di app.yaml tidak lagi diperlukan, yang berarti Anda dapat menghapus seluruh file appengine_config.py.

6. Memperbarui file aplikasi

Hanya ada satu file aplikasi, main.py, sehingga semua perubahan di bagian ini hanya memengaruhi file tersebut. Kami telah memberikan representasi bergambar dari perubahan yang akan kami lakukan untuk memigrasikan aplikasi ini ke Cloud Memorystore. Hal ini hanya untuk tujuan ilustrasi dan tidak dimaksudkan untuk Anda analisis secara cermat. Semua pekerjaan ada dalam perubahan yang kita lakukan pada kode.

Mari kita bahas satu per satu bagian ini, mulai dari atas.

Memperbarui impor

Bagian impor di main.py untuk Modul 12 menggunakan Cloud NDB dan Cloud Tasks; berikut impornya:

SEBELUM:

from flask import Flask, render_template, request
from google.appengine.api import memcache
from google.appengine.ext import ndb

Beralih ke Memorystore memerlukan pembacaan variabel lingkungan, yang berarti kita memerlukan modul os Python serta redis, klien Redis Python. Karena Redis tidak dapat menyimpan objek Python dalam cache, susun daftar kunjungan terbaru menggunakan pickle, jadi impor juga. Salah satu manfaat Memcache adalah serialisasi objek terjadi secara otomatis, sedangkan Memorystore sedikit lebih "DIY". Terakhir, upgrade dari App Engine ndb ke Cloud NDB dengan mengganti google.appengine.ext.ndb dengan google.cloud.ndb. Setelah perubahan ini, impor Anda sekarang akan terlihat seperti berikut:

SETELAH:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

Memperbarui inisialisasi

Inisialisasi Modul 12 terdiri dari membuat instance objek aplikasi Flask app dan menyetel konstanta untuk caching selama satu jam:

SEBELUM:

app = Flask(__name__)
HOUR = 3600

Penggunaan Cloud API memerlukan klien, jadi buat instance klien Cloud NDB tepat setelah Flask. Selanjutnya, dapatkan alamat IP dan nomor port untuk instance Memorystore dari variabel lingkungan yang Anda tetapkan di app.yaml. Dengan informasi tersebut, buat instance klien Redis. Berikut tampilan kode Anda setelah pembaruan tersebut:

SETELAH:

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

*Migrasi Python 3

Bagian ini bersifat opsional dan jika Anda memulai dari aplikasi Modul 12 versi Python 3. Jika demikian, ada beberapa perubahan yang diperlukan terkait impor dan inisialisasi.

Pertama, karena Memcache adalah layanan paket App Engine, penggunaannya di aplikasi Python 3 memerlukan App Engine SDK, khususnya membungkus aplikasi WSGI (serta konfigurasi yang diperlukan lainnya):

SEBELUM:

from flask import Flask, render_template, request
from google.appengine.api import memcache, wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)
HOUR = 3600

Karena kita bermigrasi ke Cloud Memorystore (bukan layanan yang dipaketkan App Engine seperti Memcache), penggunaan SDK harus dihapus. Tindakan ini cukup mudah karena Anda hanya perlu menghapus seluruh baris yang mengimpor memcache dan wrap_wsgi_app. Hapus juga baris yang memanggil wrap_wsgi_app(). Update ini membuat bagian aplikasi ini (sebenarnya, seluruh aplikasi) identik dengan versi Python 2.

SETELAH:

import os
import pickle
from flask import Flask, render_template, request
from google.cloud import ndb
import redis

app = Flask(__name__)
ds_client = ndb.Client()
HOUR = 3600
REDIS_HOST = os.environ.get('REDIS_HOST', 'localhost')
REDIS_PORT = os.environ.get('REDIS_PORT', '6379')
REDIS = redis.Redis(host=REDIS_HOST, port=REDIS_PORT)

Terakhir, hapus penggunaan SDK dari app.yaml (hapus baris: app_engine_apis: true) dan requirements.txt (hapus baris: appengine-python-standard).

Melakukan Migrasi ke Cloud Memorystore (dan Cloud NDB)

Model data Cloud NDB dimaksudkan agar kompatibel dengan model data App Engine ndb, yang berarti definisi objek Visit tetap sama. Meniru migrasi Modul 2 ke Cloud NDB, semua panggilan Datastore di store_visit() dan fetch_visits() ditambah dan disematkan dalam blok with baru (karena penggunaan pengelola konteks Cloud NDB diperlukan). Berikut adalah panggilan sebelum perubahan tersebut:

SEBELUM:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

Tambahkan blok with ds_client.context() ke kedua fungsi, dan masukkan panggilan Datastore ke dalamnya (dan diberi indentasi). Dalam hal ini, tidak ada perubahan yang diperlukan untuk panggilan itu sendiri:

SETELAH:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

Selanjutnya, mari kita lihat perubahan caching. Berikut adalah fungsi main() dari Modul 12:

SEBELUM:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    visits = memcache.get('visits')

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        memcache.set('visits', visits, HOUR)  # set() not add()

    return render_template('index.html', visits=visits)

Redis memiliki panggilan "get" dan "set", seperti Memcache. Kita hanya perlu menukar library klien masing-masing, bukan? Hampir benar. Seperti yang disebutkan sebelumnya, kita tidak dapat menyimpan daftar Python dengan Redis (karena harus diserialisasi terlebih dahulu, sesuatu yang dilakukan Memcache secara otomatis), jadi dalam panggilan set(), "pickle" kunjungan ke dalam string dengan pickle.dumps(). Demikian pula, saat mengambil kunjungan dari cache, Anda perlu meng-unpickle-nya dengan pickle.loads() tepat setelah get(). Berikut adalah handler utama setelah menerapkan perubahan tersebut:

SETELAH:

@app.route('/')
def root():
    'main application (GET) handler'
    # check for (hour-)cached visits
    ip_addr, usr_agt = request.remote_addr, request.user_agent
    visitor = '{}: {}'.format(ip_addr, usr_agt)
    rsp = REDIS.get('visits')
    visits = pickle.loads(rsp) if rsp else None

    # register visit & run DB query if cache empty or new visitor
    if not visits or visits[0].visitor != visitor:
        store_visit(ip_addr, usr_agt)
        visits = list(fetch_visits(10))
        REDIS.set('visits', pickle.dumps(visits), ex=HOUR)

    return render_template('index.html', visits=visits)

Dengan demikian, perubahan yang diperlukan dalam main.py mengonversi penggunaan Memcache di aplikasi contoh ke Cloud Memorystore telah selesai. Bagaimana dengan template HTML dan porting ke Python 3?

Memperbarui file template HTML dan melakukan porting ke Python 3?

Kejutan! Tidak ada yang perlu dilakukan di sini karena aplikasi dirancang untuk berjalan di Python 2 dan 3 tanpa perubahan kode atau library kompatibilitas. Anda akan menemukan main.py. identik di seluruh folder "SELESAI" mod13a (2.x) dan mod13b (3.x). Hal yang sama berlaku untuk requirements.txt , selain perbedaan nomor versi (jika digunakan). Karena antarmuka pengguna tidak berubah, tidak ada update untuk templates/index.html juga.

Semua yang diperlukan untuk menjalankan aplikasi ini di App Engine Python 3 telah diselesaikan sebelumnya dalam konfigurasi: perintah yang tidak diperlukan telah dihapus dari app.yaml dan appengine_config.py serta folder lib telah dihapus karena tidak digunakan di Python 3.

App Engine NDB dan Cloud NDB menyediakan caching otomatis

Meskipun kita secara eksplisit melakukan migrasi dari App Engine Memcache ke Cloud Memorystore, perhatikan bahwa App Engine ndb dan Cloud NDB masing-masing menyediakan caching otomatis ke Memcache atau Memorystore, untuk Python 2 atau 3. Baca tentang penyiapan cache ndb di Penyiapan cache NDB dan penyiapan cache Cloud NDB di Mengaktifkan penyiapan cache data, yang petunjuknya sangat mirip dengan petunjuk dalam codelab ini. Fitur tambahan dapat ditemukan di Opsi konteks dan transaksi.

Alasan kami tidak menggunakan caching otomatis ini adalah karena aplikasi contoh kami tidak mengkueri setiap entity Datastore (yang dapat diakses dengan mudah melalui cache). Sebagai gantinya, aplikasi ini meng-cache array entitas (kunjungan terbaru), yang merupakan kasus penggunaan yang terlalu spesifik dan tidak didukung oleh lapisan caching otomatis. Namun, aplikasi Anda dapat melakukan kueri tersebut dan memanfaatkan fitur ini, sehingga menyederhanakan penggunaan Anda secara keseluruhan.

7. Ringkasan/Pembersihan

Bagian ini mengakhiri codelab ini dengan men-deploy aplikasi, memverifikasi bahwa aplikasi berfungsi seperti yang diinginkan dan dalam output yang ditampilkan. Setelah validasi aplikasi, lakukan pembersihan dan pertimbangkan langkah selanjutnya.

Men-deploy dan memverifikasi aplikasi

Pemeriksaan terakhir adalah men-deploy aplikasi contoh. Developer Python 2: hapus dan instal ulang lib dengan perintah di bawah. (Jika Anda menginstal Python 2 dan 3 di sistem, Anda mungkin perlu menjalankan pip2 secara eksplisit.)

rm -rf ./lib
pip install -t lib -r requirements.txt

Developer Python 2 dan 3 kini dapat men-deploy aplikasi mereka dengan:

gcloud app deploy

Karena Anda hanya melakukan perbaikan di balik layar untuk layanan caching yang sama sekali berbeda, aplikasi itu sendiri akan beroperasi secara identik dengan aplikasi Modul 12 Anda:

Aplikasi visitme Modul 7

Langkah ini menyelesaikan codelab. Kami mengundang Anda untuk membandingkan aplikasi contoh yang telah diupdate dengan salah satu folder Modul 13, mod13a (Python 2) atau mod13b (Python 3).

Pembersihan

Umum

Jika Anda sudah selesai untuk saat ini, sebaiknya nonaktifkan aplikasi App Engine untuk menghindari penagihan. Namun, jika Anda ingin menguji atau bereksperimen lebih lanjut, platform App Engine memiliki kuota gratis, sehingga selama Anda tidak melebihi tingkat penggunaan tersebut, Anda tidak akan dikenai biaya. Biaya tersebut adalah untuk komputasi, tetapi mungkin juga ada biaya untuk layanan App Engine yang relevan, jadi periksa halaman harganya untuk mengetahui informasi selengkapnya. Jika migrasi ini melibatkan layanan Cloud lainnya, layanan tersebut akan ditagih secara terpisah. Dalam kedua kasus tersebut, jika berlaku, lihat bagian "Khusus untuk codelab ini" di bawah.

Untuk pengungkapan penuh, men-deploy ke platform komputasi serverless Google Cloud seperti App Engine akan menimbulkan biaya build dan penyimpanan kecil. Cloud Build memiliki kuota gratisnya sendiri seperti halnya Cloud Storage. Penyimpanan gambar tersebut menggunakan sebagian kuota tersebut. Namun, Anda mungkin tinggal di wilayah yang tidak memiliki paket gratis tersebut, jadi perhatikan penggunaan penyimpanan Anda untuk meminimalkan potensi biaya. "Folder" Cloud Storage tertentu yang harus Anda tinjau meliputi:

console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
Link penyimpanan di atas bergantung pada PROJECT_ID dan *LOC*Anda, misalnya, "us" jika aplikasi Anda dihosting di Amerika Serikat.

Di sisi lain, jika Anda tidak akan melanjutkan aplikasi ini atau codelab migrasi terkait lainnya dan ingin menghapus semuanya, hentikan project Anda.

Khusus untuk codelab ini

Layanan yang tercantum di bawah ini unik untuk codelab ini. Lihat dokumentasi setiap produk untuk mengetahui informasi selengkapnya:

Cloud Memorystore memerlukan instance dan tidak memiliki paket gratis; untuk mempelajari lebih lanjut biaya penggunaan, lihat halaman harganya.
Konektor Akses VPC Serverless Cloud memerlukan instance dan tidak memiliki tingkat gratis; untuk mempelajari lebih lanjut biaya penggunaan, lihat bagiannya di halaman harga VPC Cloud.
Cloud Datastore (Cloud Firestore dalam mode Datastore) memiliki paket gratis; lihat halaman harganya untuk mengetahui informasi selengkapnya.

Tutorial ini melibatkan penggunaan empat produk Cloud:

App Engine
Cloud Datastore
Cloud Memorystore
Cloud VPC

Berikut adalah petunjuk untuk melepaskan resource ini dan untuk menghindari/meminimalkan biaya penagihan.

Mematikan instance Memorystore dan konektor VPC

Produk ini tanpa paket gratis, jadi Anda dikenai tagihan sekarang. Jika Anda tidak mematikan project Cloud (lihat bagian berikutnya), Anda harus menghapus instance Memorystore dan konektor VPC untuk menghentikan penagihan. Mirip seperti saat Anda membuat resource ini, Anda juga dapat melepaskannya dari Konsol Cloud atau command line.

Dari Konsol Cloud

Untuk menghapus instance Memorystore, kembali ke dasbor Memorystore dan klik ID instance:

Setelah membuka halaman detail instance tersebut, klik "Hapus" dan konfirmasi:

Untuk menghapus konektor VPC, buka dasbor konektor tersebut, centang kotak di samping konektor yang ingin Anda hapus, lalu klik "Hapus" dan konfirmasi:

Dari command line

Pasangan perintah gcloud berikut menghapus instance Memorystore dan konektor VPC:

gcloud redis instances delete INSTANCE --region REGION
gcloud compute networks vpc-access connectors delete CONNECTOR --region REGION

Jika Anda belum menyetel project ID dengan gcloud config set project, Anda mungkin harus memberikan --project PROJECT_ID. Jika instance Memorystore Anda bernama demo-ms dan konektor VPC bernama demo-vpc, dan keduanya berada di region us-central1, jalankan pasangan perintah berikut dan konfirmasi:

$ gcloud redis instances delete demo-ms --region us-central1
You are about to delete instance [demo-ms] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-ms]
Waiting for operation [projects/PROJECT/locations/REGION/operations/operation-aaaaa-bbbbb-ccccc-ddddd] to complete...done.
Deleted instance [demo-ms].
$
$ gcloud compute networks vpc-access connectors delete demo-vpc --region us-central1
You are about to delete connector [demo-vpc] in [us-central1].
Any associated data will be lost.

Do you want to continue (Y/n)?

Delete request issued for: [demo-vpc]
Waiting for operation [projects/PROJECT/locations/REGION/operations/aaaaa-bbbb-cccc-dddd-eeeee] to complete...done.
Deleted connector [demo-vpc].

Setiap permintaan memerlukan waktu beberapa menit untuk dijalankan. Langkah-langkah ini bersifat opsional jika Anda memilih untuk menonaktifkan seluruh project Cloud seperti yang dijelaskan sebelumnya, tetapi Anda tetap dikenai biaya hingga proses penonaktifan selesai.

Langkah berikutnya

Selain tutorial ini, modul migrasi lain yang berfokus pada cara beralih dari layanan paket lama yang perlu dipertimbangkan mencakup:

Modul 2: bermigrasi dari App Engine ndb ke Cloud NDB
Modul 7-9: melakukan migrasi dari tugas push App Engine Task Queue ke Cloud Tasks
Modul 12-13: bermigrasi dari App Engine Memcache ke Cloud Memorystore
Modul 15-16: bermigrasi dari Blobstore App Engine ke Cloud Storage
Modul 18-19: bermigrasi dari App Engine Task Queue (pull task) ke Cloud Pub/Sub

App Engine bukan lagi satu-satunya platform serverless di Google Cloud. Jika Anda memiliki aplikasi App Engine kecil atau aplikasi yang memiliki fungsi terbatas dan ingin mengubahnya menjadi microservice mandiri, atau Anda ingin memecah aplikasi monolitik menjadi beberapa komponen yang dapat digunakan kembali, ini adalah alasan yang baik untuk mempertimbangkan beralih ke Cloud Functions. Jika containerisasi telah menjadi bagian dari alur kerja pengembangan aplikasi Anda, terutama jika terdiri dari pipeline CI/CD (continuous integration/continuous delivery atau deployment), pertimbangkan untuk bermigrasi ke Cloud Run. Skenario ini dibahas dalam modul berikut:

Bermigrasi dari App Engine ke Cloud Functions: lihat Modul 11
Melakukan migrasi dari App Engine ke Cloud Run: lihat Modul 4 untuk mem-build aplikasi dalam container dengan Docker, atau Modul 5 untuk melakukannya tanpa container, pengetahuan Docker, atau Dockerfile

Beralih ke platform serverless lain bersifat opsional, dan sebaiknya pertimbangkan opsi terbaik untuk aplikasi dan kasus penggunaan Anda sebelum melakukan perubahan apa pun.

Terlepas dari modul migrasi mana yang akan Anda pertimbangkan berikutnya, semua konten Serverless Migration Station (codelab, video, kode sumber [jika tersedia]) dapat diakses di repo open source-nya. README repo juga memberikan panduan tentang migrasi mana yang perlu dipertimbangkan dan "urutan" Modul Migrasi yang relevan.

8. Referensi lainnya

Di bawah ini tercantum resource tambahan bagi developer yang ingin mempelajari lebih lanjut Modul Migrasi ini atau yang terkait, serta produk terkait. Hal ini mencakup tempat untuk memberikan masukan tentang konten ini, link ke kode, dan berbagai bagian dokumentasi yang mungkin berguna bagi Anda.

Masalah/masukan codelab

Jika Anda menemukan masalah dengan codelab ini, telusuri masalah Anda terlebih dahulu sebelum mengajukan masalah. Link untuk menelusuri dan membuat masalah baru:

Referensi migrasi

Link ke folder repo untuk Modul 12 (START) dan Modul 13 (FINISH) dapat ditemukan pada tabel di bawah. Link tersebut juga dapat diakses dari repo untuk semua migrasi codelab App Engine yang dapat Anda clone atau download file ZIP.

Codelab	Python 2	Python 3
Modul 12	kode	kode
Modul 13 (codelab ini)	kode	kode

Referensi online

Berikut adalah referensi online yang mungkin relevan untuk tutorial ini:

App Engine

App Engine NDB dan Cloud NDB

Memcache App Engine dan Cloud Memorystore

Cloud VPC

Informasi Cloud lainnya

Python di Google Cloud Platform
Library klien Python Google Cloud
Paket "Selalu Gratis" Google Cloud
Google Cloud SDK (alat command line gcloud)
Semua dokumentasi Google Cloud

Lisensi

Karya ini dilisensikan berdasarkan Lisensi Umum Creative Commons Attribution 2.0.