Cara menggunakan blobstore App Engine (Modul 15)

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.

Codelab Modul 15 ini menjelaskan cara menambahkan penggunaan App Engine blobstore ke aplikasi contoh dari Modul 0. Kemudian, Anda akan siap memigrasikan penggunaan tersebut ke Cloud Storage di Modul 16.

Tidak menggunakan Blobstore?

Jika aplikasi Anda tidak menggunakan layanan Blobstore App Engine, lewati Modul 15-16, atau lakukan codelab ini untuk membiasakan diri dengan migrasi Blobstore.

Menggunakan library klien kustom Cloud Storage App Engine?

Jika aplikasi Anda menggunakan library klien kustom App Engine untuk Cloud Storage (GoogleAppEngineCloudStorageClient atau cloudstorage), sebaiknya Anda juga bermigrasi ke library klien Cloud Storage. Migrasi semacam itu berada di luar cakupan tutorial ini dan tidak dibahas. Beberapa langkah umum disediakan di halaman migrasi Cloud Storage.

Anda akan mempelajari cara

• Menambahkan penggunaan Blobstore API/library App Engine
• Menyimpan file yang diupload pengguna ke layanan blobstore
• Bersiap untuk langkah berikutnya dalam memigrasikan data ke Cloud Storage

Yang Anda butuhkan

• Project Google Cloud Platform dengan akun penagihan GCP yang aktif
• Keterampilan Python dasar
• Pengetahuan perintah Linux umum yang berfungsi
• Pengetahuan dasar tentang mengembangkan dan men-deploy aplikasi App Engine
• Aplikasi App Engine Modul 0 yang berfungsi (dapatkan 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

Untuk bermigrasi dari App Engine Blobstore API, tambahkan penggunaannya ke aplikasi ndb App Engine dasar yang ada dari Modul 0. Aplikasi contoh menampilkan sepuluh kunjungan terbaru kepada pengguna. Kami mengubah aplikasi untuk meminta pengguna akhir mengupload artefak (file) yang sesuai dengan "kunjungan" mereka. Jika pengguna tidak ingin melakukannya, ada opsi "lewati". Terlepas dari keputusan pengguna, halaman berikutnya merender output yang sama dengan aplikasi dari Modul 0 (dan banyak modul lain dalam seri ini). Dengan penerapan integrasi blobstore App Engine ini, kita dapat memigrasikannya ke Cloud Storage di codelab berikutnya (Modul 16).

App Engine menyediakan akses ke sistem template Django dan Jinja2, dan salah satu hal yang membuat contoh ini berbeda (selain menambahkan akses Blobstore) adalah bahwa contoh ini beralih dari penggunaan Django di Modul 0 ke Jinja2 di Modul 15. Langkah utama dalam memodernisasi aplikasi App Engine adalah memigrasikan framework web dari webapp2 ke Flask. Yang terakhir menggunakan Jinja2 sebagai sistem template defaultnya, jadi kita mulai bergerak ke arah itu dengan menerapkan Jinja2 sambil tetap menggunakan webapp2 untuk akses Blobstore. Karena Flask menggunakan Jinja2 secara default, artinya tidak ada perubahan pada template yang diperlukan di Modul 16.

3. Penyiapan/Prakerja

Sebelum melanjutkan ke bagian utama tutorial, siapkan project, dapatkan kodenya, dan deploy aplikasi dasar pengukuran untuk memulai dengan kode yang berfungsi.

1. Siapkan project

Jika Anda sudah men-deploy aplikasi Modul 0, 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 yang aktif dan App Engine diaktifkan.

2. Dapatkan aplikasi contoh dasar pengukuran

Salah satu prasyarat untuk codelab ini adalah memiliki aplikasi contoh Modul 0 yang berfungsi. Jika Anda tidak memilikinya, Anda bisa mendapatkannya dari folder "START" Modul 0 (link di bawah). Codelab ini akan memandu Anda melalui setiap langkah, yang diakhiri dengan kode yang menyerupai kode di folder "FINISH" Modul 15.

• START: Folder Modul 0 (Python 2)
• FINISH: Folder Modul 15 (Python 2)
• Seluruh repo (untuk melakukan clone atau mendownload file ZIP)

Direktori file awal (START) Modul 0 akan terlihat seperti ini:

$ ls
README.md               index.html
app.yaml                main.py

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 berhasil menjalankan langkah-langkah tersebut dan melihat aplikasi web Anda berfungsi (dengan output yang serupa dengan di bawah), Anda siap menambahkan penggunaan caching ke aplikasi Anda.

4. Update file konfigurasi

app.yaml

Tidak ada perubahan signifikan pada konfigurasi aplikasi, tetapi seperti yang disebutkan sebelumnya, kita beralih dari template Django (default) ke Jinja2, jadi untuk beralih, pengguna harus menentukan versi terbaru Jinja2 yang tersedia di server App Engine, dan Anda melakukannya dengan menambahkannya ke bagian library pihak ketiga bawaan app.yaml.

SEBELUM:

runtime: python27
threadsafe: yes
api_version: 1

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

Edit file app.yaml dengan menambahkan bagian libraries baru seperti yang Anda lihat di sini:

SETELAH:

runtime: python27
threadsafe: yes
api_version: 1

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

libraries:
- name: jinja2
  version: latest

Perlu versi library pihak ketiga yang lebih baru?

Perubahan pada app.yaml di atas tampaknya menentukan versi "terbaru" Jinja2. Namun, hal ini hanya menunjukkan versi Python 2 terbaru yang tersedia di server App Engine, bukan versi terbaru library itu sendiri. Jika Anda memerlukan versi yang lebih baru daripada yang tercantum di halaman library pihak ketiga yang didukung, jangan tambahkan ke app.yaml seperti yang diarahkan di atas. Sebagai gantinya, cantumkan di requirements.txt dan jalankan pip install -t lib -r requirements.txt untuk memaketkan/menjual versi terbaru Jinja2 (atau library pihak ketiga yang diizinkan) untuk Python 2. Library bawaan memberikan kemudahan karena tidak perlu melakukan bundling sendiri sebagai imbalan untuk (selalu) menyediakan versi terbaru.

Tidak ada file konfigurasi lain yang perlu diperbarui, jadi mari kita lanjutkan ke file aplikasi.

5. Mengubah file aplikasi

Dukungan impor dan Jinja2

Serangkaian perubahan pertama untuk main.py mencakup penambahan penggunaan Blobstore API dan penggantian template Django dengan Jinja2. Berikut perubahannya:

1. Tujuan modul os adalah membuat nama jalur file ke template Django. Karena kita beralih ke Jinja2 yang menangani hal ini, penggunaan os serta perender template Django, google.appengine.ext.webapp.template, tidak lagi diperlukan, sehingga dihapus.
2. Impor Blobstore API: google.appengine.ext.blobstore
3. Impor pengendali Blobstore yang ditemukan di framework webapp asli—pengendali ini tidak tersedia di webapp2: google.appengine.ext.webapp.blobstore_handlers
4. Impor dukungan Jinja2 dari paket webapp2_extras

SEBELUM:

import os
import webapp2
from google.appengine.ext import ndb
from google.appengine.ext.webapp import template

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

SETELAH:

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

Setelah impor, tambahkan beberapa kode boilerplate untuk mendukung penggunaan Jinja2 seperti yang ditentukan dalam dokumen webapp2_extras. Cuplikan kode berikut membungkus class handler permintaan webapp2 standar dengan fungsi Jinja2, jadi tambahkan blok kode ini ke main.py tepat setelah impor:

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))

Dukungan Jinja2 alternatif

Jika Anda tidak mengenali boilerplate Jinja2 di atas dan mengharapkan sesuatu yang lebih mirip contoh dalam dokumentasi App Engine yang menampilkan penggunaan jinja2.Environment(), kami memilih solusi webapp2extras karena solusi tersebut memberikan dukungan yang lebih baik (threading I18N).

Menambahkan dukungan Blobstore

Tidak seperti migrasi lain dalam seri ini yang mempertahankan fungsi atau output aplikasi contoh yang identik (atau hampir sama) tanpa (banyak) perubahan pada UX, contoh ini mengambil langkah yang lebih radikal dari biasanya. Daripada langsung mendaftarkan kunjungan baru lalu menampilkan sepuluh kunjungan terbaru, kami memperbarui aplikasi untuk meminta artefak file kepada pengguna untuk mendaftarkan kunjungan mereka. Kemudian, pengguna akhir dapat mengupload file yang sesuai atau memilih "Lewati" agar tidak mengupload apa pun. Setelah langkah ini selesai, halaman "kunjungan terbaru" akan ditampilkan.

Perubahan ini memungkinkan aplikasi kita menggunakan layanan Blobstore untuk menyimpan (dan mungkin merender nanti) gambar atau jenis file lainnya di halaman kunjungan terbaru.

Memperbarui model data dan menerapkan penggunaannya

Kita akan menyimpan lebih banyak data, khususnya memperbarui model data untuk menyimpan ID (yang disebut "BlobKey") file yang diupload ke Blobstore dan menambahkan referensi untuk menyimpannya di store_visit(). Karena data tambahan ini ditampilkan bersama dengan data lainnya saat kueri, fetch_visits() tetap sama.

Berikut adalah tampilan sebelum dan sesudah pembaruan ini yang menampilkan file_blob, ndb.BlobKeyProperty:

SEBELUM:

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

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)

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.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)

Berikut adalah representasi gambar dari perubahan yang telah dilakukan sejauh ini:

Mendukung upload file

Perubahan fungsionalitas yang paling signifikan adalah dukungan untuk upload file, baik meminta pengguna untuk memilih file, mendukung fitur "lewati", atau merender file yang sesuai dengan kunjungan. Semuanya adalah bagian dari gambaran besarnya. Berikut adalah perubahan yang diperlukan untuk mendukung upload file:

1. Permintaan handler utama GET tidak lagi mengambil kunjungan terbaru untuk ditampilkan. Sebagai gantinya, pengguna akan diminta untuk mengupload.
2. Saat pengguna akhir mengirimkan file untuk diupload atau melewati proses tersebut, POST dari formulir akan meneruskan kontrol ke UploadHandler baru, yang berasal dari google.appengine.ext.webapp.blobstore_handlers.BlobstoreUploadHandler.
3. Metode POST UploadHandler melakukan upload, memanggil store_visit() untuk mendaftarkan kunjungan, dan memicu pengalihan HTTP 307 untuk mengirim pengguna kembali ke "/", tempat...
4. Metode POST handler utama membuat kueri untuk (melalui fetch_visits()) dan menampilkan kunjungan terbaru. Jika pengguna memilih "lewati", tidak ada file yang diupload, tetapi kunjungan tetap terdaftar, diikuti dengan pengalihan yang sama.
5. Tampilan kunjungan terbaru mencakup kolom baru yang ditampilkan kepada pengguna, baik "lihat" yang ditautkan jika file upload tersedia atau "tidak ada" jika tidak. Perubahan ini diwujudkan dalam template HTML bersama dengan penambahan formulir upload (info selengkapnya akan segera hadir).
6. Jika pengguna akhir mengklik link "lihat" untuk kunjungan apa pun dengan video yang diupload, hal ini akan membuat permintaan GET ke ViewBlobHandler baru, yang berasal dari google.appengine.ext.webapp.blobstore_handlers.BlobstoreDownloadHandler , baik merender file jika berupa gambar (di browser jika didukung), meminta untuk mendownload jika tidak, atau menampilkan error HTTP 404 jika tidak ditemukan.
7. Selain pasangan class handler baru serta pasangan rute baru untuk mengirim traffic ke class tersebut, handler utama memerlukan metode POST baru untuk menerima pengalihan 307 yang dijelaskan di atas.

Sebelum update ini, aplikasi Module 0 hanya menampilkan handler utama dengan metode GET dan satu rute:

SEBELUM:

class MainHandler(webapp2.RequestHandler):
    'main application (GET) handler'
    def get(self):
        store_visit(self.request.remote_addr, self.request.user_agent)
        visits = fetch_visits(10)
        tmpl = os.path.join(os.path.dirname(__file__), 'index.html')
        self.response.out.write(template.render(tmpl, {'visits': visits}))

app = webapp2.WSGIApplication([
    ('/', MainHandler),
], debug=True)

Dengan penerapan update tersebut, kini ada tiga handler: 1) handler upload dengan metode POST, 2) handler download "lihat blob" dengan metode GET, dan 3) handler utama dengan metode GET dan POST. Lakukan perubahan ini agar bagian aplikasi Anda yang lain terlihat seperti di bawah.

SETELAH:

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)

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)

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)

Ada beberapa panggilan utama dalam kode yang baru saja kita tambahkan ini:

• Di MainHandler.get, ada panggilan ke blobstore.create_upload_url. Panggilan ini membuat URL yang akan dituju POST formulir, dengan memanggil pengendali upload untuk mengirim file ke Blobstore.
• Di UploadHandler.post, ada panggilan ke blobstore_handlers.BlobstoreUploadHandler.get_uploads. Inilah keajaiban sebenarnya yang memasukkan file ke Blobstore dan menampilkan ID unik dan persisten untuk file tersebut, BlobKey-nya.
• Di ViewBlobHandler.get, memanggil blobstore_handlers.BlobstoreDownloadHandler.send dengan BlobKey file akan menghasilkan pengambilan file dan meneruskannya ke browser pengguna akhir

Panggilan ini mewakili sebagian besar akses ke fitur yang ditambahkan ke aplikasi. Berikut adalah representasi bergambar dari kumpulan perubahan kedua dan terakhir pada main.py:

Memperbarui template HTML

Beberapa update pada aplikasi utama memengaruhi antarmuka pengguna (UI) aplikasi, sehingga perubahan yang sesuai diperlukan dalam template web, bahkan dua perubahan:

1. Formulir upload file diperlukan dengan 3 elemen input: file dan sepasang tombol kirim untuk upload file dan lewati.
2. Perbarui output kunjungan terbaru dengan menambahkan link "lihat" untuk kunjungan dengan upload file yang sesuai atau "tidak ada" jika tidak ada.

SEBELUM:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

</body>
</html>

Terapkan perubahan dalam daftar di atas untuk menyusun template yang diperbarui:

SETELAH:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
<body>

<h1>VisitMe example</h1>
{% if upload_url %}

<h3>Welcome... upload a file? (optional)</h3>
<form action="{{ upload_url }}" method="POST" enctype="multipart/form-data">
    <input type="file" name="file"><p></p>
    <input type="submit"> <input type="submit" value="Skip">
</form>

{% else %}

<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
<li>{{ visit.timestamp.ctime() }}
    <i><code>
    {% if visit.file_blob %}
        (<a href="/view/{{ visit.file_blob }}" target="_blank">view</a>)
    {% else %}
        (none)
    {% endif %}
    </code></i>
    from {{ visit.visitor }}
</li>
{% endfor %}
</ul>

{% endif %}

</body>
</html>

Gambar ini menunjukkan pembaruan yang diperlukan pada index.html:

Perubahan terakhir adalah Jinja2 lebih memilih templatenya di folder templates, jadi buat folder tersebut dan pindahkan index.html ke dalamnya. Dengan langkah terakhir ini, Anda telah menyelesaikan semua perubahan yang diperlukan untuk menambahkan penggunaan Blobstore ke aplikasi contoh Modul 0.

(opsional) "Peningkatan" Cloud Storage

Penyimpanan Blobstore akhirnya berkembang menjadi Cloud Storage itu sendiri. Artinya, upload Blobstore dapat dilihat di konsol Cloud, khususnya browser Cloud Storage. Pertanyaannya adalah di mana. Jawabannya adalah bucket Cloud Storage default aplikasi App Engine Anda. Namanya adalah nama domain lengkap aplikasi App Engine Anda, PROJECT_ID.appspot.com. Sangat praktis karena semua project ID bersifat unik, bukan?

Perubahan yang dilakukan pada aplikasi contoh akan memasukkan file yang diupload ke dalam bucket tersebut, tetapi developer memiliki opsi untuk memilih lokasi yang lebih spesifik. Bucket default dapat diakses secara terprogram melalui google.appengine.api.app_identity.get_default_gcs_bucket_name(), yang memerlukan impor baru jika Anda ingin mengakses nilai ini, misalnya untuk digunakan sebagai awalan dalam mengatur file yang diupload. Misalnya, mengurutkan menurut jenis file:

Untuk menerapkan hal seperti itu pada gambar, misalnya, Anda akan memiliki kode seperti ini bersama dengan beberapa kode yang memeriksa jenis file untuk memilih nama bucket yang diinginkan:

ROOT_BUCKET = app_identity.get_default_gcs_bucket_name()
IMAGE_BUCKET = '%s/%s' % (ROOT_BUCKET, 'images')

Anda juga akan memvalidasi gambar yang diupload menggunakan alat seperti modul imghdr Python Standard Library untuk mengonfirmasi jenis gambar. Terakhir, Anda mungkin ingin membatasi ukuran upload jika ada oknum berniat jahat.

Anggap saja semua itu telah dilakukan. Bagaimana cara mengupdate aplikasi kami untuk mendukung penentuan lokasi penyimpanan file yang diupload? Kuncinya adalah mengubah panggilan ke blobstore.create_upload_url di MainHandler.get untuk menentukan lokasi yang diinginkan di Cloud Storage untuk upload dengan menambahkan parameter gs_bucket_name seperti ini:

blobstore.create_upload_url('/upload', gs_bucket_name=IMAGE_BUCKET))

Karena ini adalah update opsional jika Anda ingin menentukan tujuan upload, update ini bukan bagian dari file main.py di repo. Sebagai gantinya, alternatif bernama main-gcs.py tersedia untuk Anda tinjau di repo. Daripada menggunakan "folder" bucket terpisah, kode di main-gcs.py menyimpan upload di bucket "root" (PROJECT_ID.appspot.com) seperti main.py, tetapi menyediakan struktur yang Anda butuhkan jika Anda ingin mendapatkan sampel menjadi sesuatu yang lebih seperti yang diisyaratkan di bagian ini. Berikut adalah ilustrasi "perbedaan" antara main.py dan main-gcs.py.

6. 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 langkah-langkah pembersihan dan pertimbangkan langkah berikutnya.

Men-deploy dan memverifikasi aplikasi

Deploy ulang aplikasi Anda dengan gcloud app deploy, dan konfirmasi bahwa aplikasi berfungsi seperti yang diiklankan, berbeda dalam pengalaman pengguna (UX) dari aplikasi Modul 0. Sekarang ada dua layar berbeda di aplikasi Anda, yang pertama adalah perintah formulir upload file kunjungan:

Dari sana, pengguna akhir dapat mengupload file dan mengklik "Kirim" atau mengklik "Lewati" agar tidak mengupload apa pun. Dalam kedua kasus tersebut, hasilnya adalah layar kunjungan terbaru, yang kini dilengkapi dengan link "lihat" atau "tidak ada" di antara stempel waktu kunjungan dan informasi pengunjung:

Selamat karena telah menyelesaikan codelab ini dengan menambahkan penggunaan Blobstore App Engine ke aplikasi contoh Modul 0. Kode Anda sekarang harus cocok dengan yang ada di folder FINISH (Modul 15). main-gcs.py alternatif juga ada di folder tersebut.

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:

• Layanan Blobstore App Engine termasuk dalam kuota dan batas Data Tersimpan, jadi tinjau kuota dan batas tersebut serta halaman harga untuk layanan paket lama.
• Layanan App Engine Datastore disediakan oleh Cloud Datastore (Cloud Firestore dalam mode Datastore) yang juga memiliki paket gratis; lihat halaman harganya untuk mengetahui informasi selengkapnya.

Langkah berikutnya

Migrasi logis berikutnya yang perlu dipertimbangkan dibahas dalam Modul 16, yang menunjukkan cara bermigrasi dari layanan Blobstore App Engine ke penggunaan library klien Cloud Storage. Manfaat mengupgrade mencakup kemampuan untuk mengakses lebih banyak fitur Cloud Storage, memahami library klien yang berfungsi untuk aplikasi di luar App Engine, baik di Google Cloud, cloud lain, atau bahkan di lokal. Jika merasa tidak memerlukan semua fitur yang tersedia dari Cloud Storage atau khawatir tentang pengaruhnya terhadap biaya, Anda dapat tetap menggunakan Blobstore App Engine.

Selain Modul 16, ada banyak kemungkinan migrasi lainnya seperti Cloud NDB dan Cloud Datastore, Cloud Tasks, atau Cloud Memorystore. Ada juga migrasi lintas produk ke Cloud Run dan Cloud Functions. Repo migrasi menampilkan semua contoh kode, menautkan Anda ke semua codelab dan video yang tersedia, serta memberikan panduan tentang migrasi yang perlu dipertimbangkan dan "urutan" migrasi yang relevan.

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:

• Telusuri masalah
• Ajukan masukan/masukan baru

Referensi migrasi

Link ke folder repo untuk Modul 0 (START) dan Modul 15 (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 0	kode	T/A
Modul 15 (codelab ini)	kode	T/A

Referensi online

Berikut adalah referensi online yang mungkin relevan untuk tutorial ini:

App Engine

• Layanan Blobstore App Engine
• Kuota dan batas Data Tersimpan App Engine
• Dokumentasi App Engine
• Runtime Python 2 App Engine (lingkungan standar)
• Menggunakan library bawaan App Engine di App Engine Python 2
• Informasi harga dan kuota App Engine
• Peluncuran platform App Engine generasi kedua (2018)
• Membandingkan platform generasi pertama & kedua
• Dukungan jangka panjang untuk runtime lama
• Repositori contoh migrasi dokumentasi
• Repo contoh migrasi yang dikontribusikan komunitas

Google Cloud

• 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

Python

• Sistem template Django dan Jinja2
• Framework web webapp2
• Dokumentasi webapp2
• webapp2_extras link
• Dokumentasi Jinja2 webapp2_extras

Video

• Serverless Migration Station
• Ekspedisi Tanpa Server
• Berlangganan Google Cloud Tech
• Subscribe ke Google Developers

Lisensi

Karya ini dilisensikan berdasarkan Lisensi Umum Creative Commons Attribution 2.0.