Bermigrasi dari Blobstore App Engine ke Cloud Storage (Modul 16)

1. Ringkasan

Rangkaian codelab Stasiun Migrasi Serverless (tutorial interaktif dan mandiri) dan video terkait bertujuan untuk membantu developer tanpa server Google Cloud memodernisasi aplikasi mereka dengan memandu mereka melalui satu atau beberapa migrasi, terutama yang beralih dari layanan lama. Dengan melakukannya, aplikasi Anda akan menjadi lebih portabel serta memberi Anda lebih banyak opsi dan fleksibilitas, sehingga Anda dapat berintegrasi dengan dan mengakses lebih banyak produk Cloud serta melakukan upgrade 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 platform lainnya jika berlaku.

Codelab ini mengajarkan cara bermigrasi dari App Engine Blobstore ke Cloud Storage. Ada juga migrasi implisit dari:

Lihat modul migrasi terkait untuk mendapatkan informasi langkah demi langkah lebih lanjut.

Anda akan mempelajari cara

  • Menambahkan penggunaan library/library App Engine Blobstore
  • Menyimpan upload pengguna ke layanan Blobstore
  • Bersiap untuk langkah berikutnya untuk bermigrasi ke Cloud Storage

Yang Anda butuhkan

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 dimulai dengan aplikasi contoh dari Modul 15 dan menunjukkan cara bermigrasi dari Blobstore (dan NDB) ke Cloud Storage (dan Cloud NDB). Proses migrasi melibatkan penggantian dependensi pada layanan paket lama App Engine, yang memungkinkan Anda memindahkan aplikasi ke platform serverless Cloud lainnya atau platform hosting lainnya jika diinginkan.

Migrasi ini memerlukan upaya yang lebih banyak dibandingkan migrasi lainnya dalam seri ini. Blobstore memiliki dependensi pada framework webapp asli, dan itulah alasan aplikasi contoh menggunakan framework webapp2, bukan Flask. Tutorial ini menampilkan migrasi ke Cloud Storage, Cloud NDB, Flask, dan Python 3.

Aplikasi masih mencatat "kunjungan" pengguna akhir dan menampilkan sepuluh yang terbaru, tetapi codelab sebelumnya (Modul 15) menambahkan fungsi baru untuk mengakomodasi penggunaan Blobstore: aplikasi meminta pengguna akhir untuk mengupload artefak (file) yang sesuai dengan "kunjungan" mereka. Pengguna dapat melakukannya atau memilih "lewati" atau tidak menggunakannya. Terlepas dari keputusan pengguna, halaman berikutnya akan merender output yang sama seperti inkarnasi sebelumnya dari aplikasi ini, menampilkan kunjungan terbaru. Satu perubahan tambahan adalah kunjungan dengan artefak yang sesuai menampilkan "tampilan" link untuk menampilkan artefak kunjungan. Codelab ini menerapkan migrasi yang disebutkan sebelumnya sambil mempertahankan fungsi yang dijelaskan.

3. Penyiapan/Prakerja

Sebelum masuk ke bagian utama tutorial, mari kita siapkan project, dapatkan kodenya, lalu deploy aplikasi dasar pengukuran sehingga kita tahu bahwa kita memulai dengan kode yang berfungsi.

1. Siapkan project

Jika Anda sudah men-deploy aplikasi Modul 15, sebaiknya gunakan kembali project (dan kode) yang sama. Atau, Anda dapat membuat project baru atau menggunakan kembali project lain yang sudah ada. Pastikan project memiliki akun penagihan aktif dan App Engine diaktifkan.

2. Dapatkan aplikasi contoh dasar pengukuran

Salah satu prasyarat untuk codelab ini adalah memiliki aplikasi contoh Modul 15 yang berfungsi. Jika tidak memilikinya, Anda bisa mendapatkannya dari Modul 15 "MULAI" (tautan di bawah). Codelab ini memandu Anda melalui setiap langkah, yang diakhiri dengan kode yang mirip dengan yang ada di Modul 16 "FINISH" folder tersebut.

Direktori file awal Modul 15 akan terlihat seperti ini:

$ ls
README.md       app.yaml        main-gcs.py     main.py         templates

File main-gcs.py adalah versi alternatif main.py dari Modul 15 yang memungkinkan pemilihan bucket Cloud Storage yang berbeda dengan URL default yang ditetapkan aplikasi berdasarkan ID project: PROJECT_ID.appspot.com. File ini tidak berperan dalam codelab (Modul 16) ini, selain teknik migrasi serupa yang dapat diterapkan ke file tersebut jika diinginkan.

3. Deploy (ulang) aplikasi dasar pengukuran

Langkah prakerja yang tersisa untuk dijalankan sekarang:

  1. Biasakan kembali diri Anda dengan alat command-line gcloud
  2. Deploy kembali aplikasi contoh dengan gcloud app deploy
  3. Konfirmasikan bahwa aplikasi berjalan di App Engine tanpa masalah

Setelah Anda berhasil menjalankan langkah-langkah tersebut dan mengonfirmasi bahwa aplikasi Modul 15 Anda berfungsi. Halaman awal menyambut pengguna dengan formulir yang meminta file artefak kunjungan untuk diupload bersama dengan opsi, "lewati" , untuk memilih tidak ikut:

f5b5f9f19d8ae978.png

Setelah pengguna mengupload file atau melewati, aplikasi akan merender "kunjungan terbaru" yang sudah dikenal halaman:

f5ac6b98ee8a34cb.png

Kunjungan yang menampilkan artefak akan memiliki "tampilan" di sebelah kanan stempel waktu kunjungan untuk menampilkan (atau mendownload) artefak. Setelah mengonfirmasi fungsi aplikasi, Anda siap untuk bermigrasi dari layanan lama App Engine (webapp2, NDB, Blobstore) ke alternatif kontemporer (Flask, Cloud NDB, Cloud Storage).

4. Update file konfigurasi

Tiga file konfigurasi berperan untuk versi terbaru aplikasi kita. Tugas yang diperlukan adalah:

  1. Update library pihak ketiga bawaan yang diperlukan di app.yaml serta biarkan pintu untuk migrasi Python 3 terbuka
  2. Menambahkan requirements.txt, yang menentukan semua library wajib yang bukan bawaan
  3. Tambahkan appengine_config.py agar aplikasi mendukung library pihak ketiga bawaan dan non-bawaan

app.yaml

Edit file app.yaml Anda dengan memperbarui bagian libraries. Hapus jinja2 lalu tambahkan grpcio, setuptools, dan ssl. Pilih versi terbaru yang tersedia untuk ketiga library. Tambahkan juga perintah runtime Python 3, tetapi berikan komentar. Setelah selesai, akan terlihat seperti ini (jika Anda memilih Python 3.9):

SEBELUM:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: jinja2
  version: latest

SETELAH:

#runtime: python39
runtime: python27
threadsafe: yes
api_version: 1

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

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

Perubahan ini terutama berkaitan dengan library bawaan Python 2 yang tersedia di server App Engine (jadi Anda tidak perlu memaketkannya sendiri). Kita menghapus Jinja2 karena dilengkapi dengan Flask, yang akan kita tambahkan ke reqs.txt. Setiap kali library klien Google Cloud, seperti library untuk Cloud NDB dan Cloud Storage, digunakan, grpcio dan alat penyiapan akan diperlukan. Terakhir, Cloud Storage sendiri memerlukan library SSL. Perintah runtime yang dikomentari di bagian atas adalah saat Anda siap mentransfer aplikasi ini ke Python 3. Kami akan membahas topik ini di akhir tutorial ini.

requirements.txt

Tambahkan file requirements.txt, yang memerlukan framework Flask, serta library klien Cloud NDB dan Cloud Storage, yang tidak ada yang merupakan bawaan. Buat file dengan konten ini:

flask
google-cloud-ndb
google-cloud-storage

Runtime Python 2 App Engine memerlukan penggabungan sendiri library pihak ketiga non-bawaan, jadi jalankan perintah berikut untuk menginstal library ini ke dalam folder lib:

pip install -t lib -r requirements.txt

Jika Anda memiliki Python 2 dan 3 pada mesin pengembangan, Anda mungkin harus menggunakan perintah pip2 untuk memastikan mendapatkan versi Python 2 dari library ini. Setelah mengupgrade ke Python 3, Anda tidak perlu lagi melakukan bundle mandiri.

appengine_config.py

Tambahkan file appengine_config.py yang mendukung library pihak ketiga bawaan dan non-bawaan. Buat file dengan konten ini:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

Langkah-langkah yang baru saja diselesaikan harus mirip atau sama dengan langkah-langkah yang tercantum di bagian Menginstal library untuk aplikasi Python 2 di dokumen App Engine, dan lebih khusus lagi, konten appengine_config.py harus sesuai dengan yang tercantum di Langkah 5.

Pekerjaan pada file konfigurasi telah selesai, jadi mari kita lanjutkan ke aplikasi.

5. Mengubah file aplikasi

Impor

Rangkaian perubahan pertama untuk main.py mencakup menukar semua hal yang diganti. Berikut yang akan berubah:

  1. webapp2 diganti dengan Flask
  2. Gunakan Jinja2 yang disertakan dengan Flask, bukan Jinja2 dari webapp2_extras
  3. Blobstore App Engine dan NDB diganti dengan Cloud NDB dan Cloud Storage
  4. Pengendali Blobstore di webapp diganti dengan kombinasi dari modul library standar io, Flask, dan utilitas werkzeug
  5. Secara default, Blobstore menulis ke bucket Cloud Storage yang diberi nama berdasarkan URL aplikasi Anda (PROJECT_ID.appspot.com). Karena kita melakukan porting ke library klien Cloud Storage, google.auth digunakan untuk mendapatkan project ID guna menentukan nama bucket yang sama persis. (Anda dapat mengubah nama bucket karena tidak di-hardcode lagi.)

SEBELUM:

import webapp2
from webapp2_extras import jinja2
from google.appengine.ext import blobstore, ndb
from google.appengine.ext.webapp import blobstore_handlers

Terapkan perubahan dalam daftar di atas dengan mengganti bagian impor saat ini di main.py dengan cuplikan kode di bawah.

SETELAH:

import io

from flask import (Flask, abort, redirect, render_template,
        request, send_file, url_for)
from werkzeug.utils import secure_filename

import google.auth
from google.cloud import exceptions, ndb, storage

Inisialisasi dan dukungan Jinja2 yang tidak perlu

Blok kode berikutnya yang akan diganti adalah BaseHandler yang menentukan penggunaan Jinja2 dari webapp2_extras. Ini tidak diperlukan karena Jinja2 dilengkapi dengan Flask dan merupakan mesin pembuat template default, jadi hapus.

Di sisi Modul 16, buat instance objek yang tidak kita miliki di aplikasi lama. Hal ini termasuk menginisialisasi aplikasi Flask dan membuat klien API untuk Cloud NDB dan Cloud Storage. Terakhir, kita telah menggabungkan nama bucket Cloud Storage seperti yang dijelaskan di atas di bagian impor. Berikut adalah sebelum dan sesudah menerapkan pembaruan ini:

SEBELUM:

class BaseHandler(webapp2.RequestHandler):
    'Derived request handler mixing-in Jinja2 support'
    @webapp2.cached_property
    def jinja2(self):
        return jinja2.get_jinja2(app=self.app)

    def render_response(self, _template, **context):
        self.response.write(self.jinja2.render_template(_template, **context))

SETELAH:

app = Flask(__name__)
ds_client = ndb.Client()
gcs_client = storage.Client()
_, PROJECT_ID = google.auth.default()
BUCKET = '%s.appspot.com' % PROJECT_ID

Memperbarui akses Datastore

Cloud NDB sebagian besar kompatibel dengan App Engine NDB. Satu perbedaan yang sudah dibahas adalah kebutuhan akan klien API. Alasan lainnya adalah, akses Datastore memerlukan kontrol yang dikontrol oleh pengelola konteks Python klien API. Pada dasarnya, hal ini berarti semua panggilan akses Datastore yang menggunakan library klien Cloud NDB hanya dapat terjadi dalam blok with Python.

Itu adalah satu perubahan; satu lagi adalah Blobstore dan objeknya, misalnya, BlobKey tidak didukung oleh Cloud Storage. Jadi, ubah file_blob menjadi ndb.StringProperty. Berikut adalah class model data serta fungsi store_visit() dan fetch_visits() yang diperbarui yang mencerminkan perubahan ini:

SEBELUM:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)
    file_blob = ndb.BlobKeyProperty()

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

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

SETELAH:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)
    file_blob = ndb.StringProperty()

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

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

Berikut adalah gambaran dari perubahan yang telah dilakukan sejauh ini:

a8f74ca392275822.png

Memperbarui pengendali

Pengendali upload

Pengendali di webapp2 adalah class saat berfungsi di Flask. Sebagai ganti metode kata kerja HTTP, Flask menggunakan kata kerja untuk mendekorasi fungsi. Blobstore dan pengendali webapp-nya diganti dengan fungsi dari Cloud Storage, serta Flask dan utilitasnya:

SEBELUM:

class UploadHandler(blobstore_handlers.BlobstoreUploadHandler):
    'Upload blob (POST) handler'
    def post(self):
        uploads = self.get_uploads()
        blob_id = uploads[0].key() if uploads else None
        store_visit(self.request.remote_addr, self.request.user_agent, blob_id)
        self.redirect('/', code=307)

SETELAH:

@app.route('/upload', methods=['POST'])
def upload():
    'Upload blob (POST) handler'
    fname = None
    upload = request.files.get('file', None)
    if upload:
        fname = secure_filename(upload.filename)
        blob = gcs_client.bucket(BUCKET).blob(fname)
        blob.upload_from_file(upload, content_type=upload.content_type)
    store_visit(request.remote_addr, request.user_agent, fname)
    return redirect(url_for('root'), code=307)

Beberapa catatan terkait pembaruan ini:

  • Bukan blob_id, artefak file kini diidentifikasi berdasarkan nama file (fname) jika ada, dan None jika tidak ada (pengguna memilih tidak mengupload file).
  • Handler Blobstore memisahkan proses upload dari penggunanya, tetapi Cloud Storage tidak memisahkannya. Jadi, Anda dapat melihat kode yang baru ditambahkan yang menetapkan lokasi dan objek blob file (bucket) serta panggilan yang melakukan upload sebenarnya. (upload_from_file()).
  • webapp2 menggunakan tabel perutean di bagian bawah file aplikasi, sedangkan rute Flask ditemukan di setiap pengendali yang didekorasi.
  • Kedua pengendali melengkapi fungsinya dengan mengalihkan ke beranda ( / ) sekaligus mempertahankan permintaan POST dengan kode pengembalian HTTP 307.

Pengendali download

Memperbarui pengendali download mengikuti pola yang serupa dengan pengendali upload, hanya saja kode yang perlu dilihat lebih sedikit. Ganti fungsi Blobstore dan webapp dengan Cloud Storage dan Flask yang setara:

SEBELUM:

class ViewBlobHandler(blobstore_handlers.BlobstoreDownloadHandler):
    'view uploaded blob (GET) handler'
    def get(self, blob_key):
        self.send_blob(blob_key) if blobstore.get(blob_key) else self.error(404)

SETELAH:

@app.route('/view/<path:fname>')
def view(fname):
    'view uploaded blob (GET) handler'
    blob = gcs_client.bucket(BUCKET).blob(fname)
    try:
        media = blob.download_as_bytes()
    except exceptions.NotFound:
        abort(404)
    return send_file(io.BytesIO(media), mimetype=blob.content_type)

Catatan terkait pembaruan ini:

  • Sekali lagi, Flask mendekorasi fungsi pengendali dengan rutenya sementara webapp melakukannya dalam tabel perutean di bagian bawah, jadi kenali sintaksis pencocokan pola yang terakhir ('/view/([^/]+)?') vs. Flask ('/view/<path:fname>').
  • Seperti pengendali upload, diperlukan sedikit pekerjaan lagi di sisi Cloud Storage untuk fungsi yang diabstraksi oleh pengendali Blobstore, yaitu mengidentifikasi file (blob) yang dimaksud dan secara eksplisit mendownload panggilan metode send_blob() tunggal biner vs. pengendali Blobstore.
  • Dalam kedua kasus tersebut, error HTTP 404 akan ditampilkan kepada pengguna jika artefak tidak ditemukan.

Pengendali utama

Perubahan terakhir pada aplikasi utama terjadi di pengendali utama. Metode kata kerja HTTP webapp2 diganti dengan fungsi tunggal yang menggabungkan fungsinya. Ganti class MainHandler dengan fungsi root() dan hapus tabel perutean webapp2 seperti yang ditunjukkan di bawah ini:

SEBELUM:

class MainHandler(BaseHandler):
    'main application (GET/POST) handler'
    def get(self):
        self.render_response('index.html',
                upload_url=blobstore.create_upload_url('/upload'))

    def post(self):
        visits = fetch_visits(10)
        self.render_response('index.html', visits=visits)

app = webapp2.WSGIApplication([
    ('/', MainHandler),
    ('/upload', UploadHandler),
    ('/view/([^/]+)?', ViewBlobHandler),
], debug=True)

SETELAH:

@app.route('/', methods=['GET', 'POST'])
def root():
    'main application (GET/POST) handler'
    context = {}
    if request.method == 'GET':
        context['upload_url'] = url_for('upload')
    else:
        context['visits'] = fetch_visits(10)
    return render_template('index.html', **context)

Bukan metode get() dan post() terpisah, keduanya adalah pernyataan if-else di root(). Selain itu, karena root() adalah fungsi tunggal, hanya ada satu panggilan untuk merender template untuk GET dan POST, sedangkan hal ini tidak dimungkinkan di webapp2.

Berikut adalah representasi gambar dari kumpulan perubahan kedua dan terakhir ini pada main.py:

5ec38818c32fec2.pngS

(opsional) "Peningkatan" kompatibilitas mundur

Jadi solusi yang dibuat di atas berfungsi dengan sempurna... tetapi hanya jika Anda memulai dari awal dan tidak memiliki file yang dibuat oleh Blobstore. Karena kami mengupdate aplikasi untuk mengidentifikasi file berdasarkan nama file, bukan BlobKey, aplikasi Modul 16 yang sudah selesai apa adanya tidak akan dapat melihat file Blobstore. Dengan kata lain, kami membuat perubahan inkompatibilitas mundur saat melakukan migrasi ini. Sekarang kami menyajikan versi alternatif main.py yang disebut main-migrate.py (ditemukan di repo) yang mencoba menjembatani kesenjangan ini.

"Ekstensi" pertama untuk mendukung file yang dibuat Blobstore adalah model data yang memiliki BlobKeyProperty (selain StringProperty untuk file yang dibuat Cloud Storage):

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)
    file_blob = ndb.BlobKeyProperty()  # backwards-compatibility
    file_gcs  = ndb.StringProperty()

Properti file_blob akan digunakan untuk mengidentifikasi file yang dibuat Blobstore, sedangkan file_gcs digunakan untuk file Cloud Storage. Sekarang saat membuat kunjungan baru, simpan nilai secara eksplisit di file_gcs dan bukan file_blob, sehingga store_visit akan terlihat sedikit berbeda:

SEBELUM:

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

SETELAH:

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

Saat mengambil kunjungan terbaru, "normalisasi" data sebelum mengirimkannya ke {i>template<i}:

SEBELUM:

@app.route('/', methods=['GET', 'POST'])
def root():
    'main application (GET/POST) handler'
    context = {}
    if request.method == 'GET':
        context['upload_url'] = url_for('upload')
    else:
        context['visits'] = fetch_visits(10)
    return render_template('index.html', **context)

SETELAH:

@app.route('/', methods=['GET', 'POST'])
def root():
    'main application (GET/POST) handler'
    context = {}
    if request.method == 'GET':
        context['upload_url'] = url_for('upload')
    else:
        context['visits'] = etl_visits(fetch_visits(10))
    return render_template('index.html', **context)

Selanjutnya, konfirmasi keberadaan file_blob atau file_gcs (atau tidak keduanya). Jika ada file yang tersedia, pilih file yang ada dan gunakan ID tersebut (BlobKey untuk file yang dibuat Blobstore atau nama file untuk file yang dibuat Cloud Storage). Ketika kami mengatakan "File buatan Cloud Storage," maksudnya adalah file yang dibuat menggunakan library klien Cloud Storage. Blobstore juga juga menulis ke Cloud Storage, tetapi dalam hal ini, file tersebut adalah file yang dibuat oleh Blobstore.

Yang lebih penting, fungsi etl_visits() apa yang digunakan untuk menormalkan atau melakukan ETL (mengekstrak, mentransformasi, dan memuat) data untuk pengguna akhir? Tampilannya terlihat seperti ini:

def etl_visits(visits):
    return [{
            'visitor': v.visitor,
            'timestamp': v.timestamp,
            'file_blob': v.file_gcs if hasattr(v, 'file_gcs') \
                    and v.file_gcs else v.file_blob
            } for v in visits]

Hasilnya mungkin terlihat seperti yang Anda harapkan: kode berulang melalui semua kunjungan, dan untuk setiap kunjungan, mengambil data pengunjung dan stempel waktu secara verbatim, lalu memeriksa apakah file_gcs atau file_blob ada, dan jika ya, memilih salah satunya (atau None jika tidak ada).

Berikut adalah ilustrasi perbedaan antara main.py dan main-migrate.py:

718b05b2adadb2e1.pngS

Jika Anda memulai dari awal tanpa file yang dibuat Blobstore, gunakan main.py, tetapi jika Anda sedang melakukan transisi dan ingin file pendukung yang dibuat oleh Blobstore dan Cloud Storage, lihat main-migrate.py sebagai contoh cara menangani skenario seperti membantu merencanakan migrasi untuk aplikasi Anda sendiri. Saat melakukan migrasi yang kompleks, kasus khusus cenderung muncul, sehingga contoh ini dimaksudkan untuk menunjukkan afinitas yang lebih besar untuk memodernisasi aplikasi sungguhan dengan data nyata.

6. Ringkasan/Pembersihan

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

Men-deploy dan memverifikasi aplikasi

Sebelum men-deploy ulang aplikasi Anda, pastikan untuk menjalankan pip install -t lib -r requirements.txt guna mendapatkan library pihak ketiga yang dipaketkan sendiri tersebut di folder lib. Jika Anda ingin menjalankan solusi yang kompatibel dengan versi lama, ganti nama main-migrate.py sebagai main.py terlebih dahulu. Sekarang jalankan gcloud app deploy, dan pastikan aplikasi berfungsi identik dengan aplikasi Modul 15. Layar formulir akan terlihat seperti ini:

f5b5f9f19d8ae978.png

Halaman kunjungan terbaru akan terlihat seperti ini:

f5ac6b98ee8a34cb.png

Selamat, Anda telah menyelesaikan codelab ini dengan mengganti Blobstore App Engine dengan Cloud Storage, App Engine NDB dengan Cloud NDB, dan webapp2 dengan Flask. Kode Anda sekarang seharusnya cocok dengan yang ada di folder FINISH (Modul 16). main-migrate.py alternatif juga ada di folder tersebut.

"Migrasi" Python 3

Hanya diperlukan perintah Python 3 runtime di bagian atas app.yaml yang diperlukan untuk mem-port aplikasi ini ke Python 3. Kode sumbernya sendiri sudah kompatibel dengan Python 3, jadi tidak diperlukan perubahan di sana. Untuk men-deploy ini sebagai aplikasi Python 3, jalankan langkah-langkah berikut:

  1. Hapus tanda komentar pada perintah runtime Python 3 di bagian atas app.yaml.
  2. Hapus semua baris lainnya di app.yaml.
  3. Hapus file appengine_config.py. (tidak digunakan di runtime Python 3)
  4. Hapus folder lib jika ada. (tidak diperlukan dengan runtime Python 3)

Pembersihan

Umum

Jika sudah selesai untuk saat ini, sebaiknya nonaktifkan aplikasi App Engine agar tidak menimbulkan penagihan. Namun, jika Anda ingin menguji atau bereksperimen lagi, platform App Engine memiliki kuota gratis, dan asalkan Anda tidak melebihi tingkat penggunaan tersebut, Anda tidak akan dikenai biaya. Itu berlaku 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 "Khusus untuk codelab ini" di bawah ini.

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

  • 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*asi Anda, misalnya, "us" jika aplikasi Anda dihosting di AS.

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

Khusus untuk codelab ini

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

Perlu diperhatikan bahwa jika Anda bermigrasi dari Modul 15 ke 16, Anda masih memiliki data di Blobstore. Oleh karena itu, mengapa kami menyertakan informasi harga di atas.

Langkah berikutnya

Selain tutorial ini, modul migrasi lain yang berfokus untuk beralih dari layanan paket lama yang perlu dipertimbangkan meliputi:

  • Modul 2: bermigrasi dari App Engine ndb ke Cloud NDB
  • Modul 7-9: bermigrasi dari tugas push Task Queue App Engine ke Cloud Tasks
  • Modul 12-13: bermigrasi dari Memcache App Engine ke Cloud Memorystore
  • Modul 18-19: bermigrasi dari Task Queue App Engine (tugas pull) 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, berikut adalah alasan bagus untuk mempertimbangkan beralih ke Cloud Functions. Jika containerization telah menjadi bagian dari alur kerja pengembangan aplikasi Anda, terutama jika terdiri dari pipeline CI/CD (continuous integration/continuous delivery atau deployment), sebaiknya lakukan migrasi ke Cloud Run. Skenario ini dibahas dalam modul berikut:

  • Bermigrasi dari App Engine ke Cloud Functions: lihat Modul 11
  • Bermigrasi dari App Engine ke Cloud Run: lihat Modul 4 untuk menyimpan aplikasi Anda ke dalam container dengan Docker, atau Modul 5 untuk melakukannya tanpa container, pengetahuan Docker, atau Dockerfile

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

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

7. Referensi lainnya

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 15 (START) dan Modul 16 (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 15

kode

T/A

Modul 16 (codelab ini)

kode

(sama seperti Python 2)

Sumber daya {i>online<i}

Di bawah ini adalah referensi online yang mungkin relevan untuk tutorial ini:

App Engine Blobstore dan Cloud Storage

Platform App Engine

Informasi Cloud lainnya

Python

Video

Lisensi

Karya ini dilisensikan berdasarkan Lisensi Umum Creative Commons Attribution 2.0.