Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud
In the previous
episode of the Serverless Migration
Station video series, developers learned how to containerize their App Engine code for Cloud Run using Docker. While Docker has gained popularity over the past
decade, not everyone has containers integrated into their daily development workflow, and some
prefer "containerless" solutions but know that containers can be beneficial. Well today's
video is just for you, showing how you can still get your apps onto Cloud Run, even If you
don't have much experience with Docker, containers, nor Dockerfile
s.
App Engine isn't going away as Google has expressed long-term support for legacy runtimes on the platform, so those who prefer source-based deployments can stay where they are so this is an optional migration. Moving to Cloud Run is for those who want to explicitly move to containerization.
Migrating to Cloud Run with Cloud Buildpacks video
So how can apps be containerized without Docker? The answer is buildpacks, an open-source technology that makes it
fast and easy for you to create secure, production-ready container images from source code,
without a Dockerfile
. Google Cloud Buildpacks
adheres to the buildpacks open
specification and allows
users to create images that run on all GCP container platforms: Cloud Run
(fully-managed), Anthos, and Google Kubernetes Engine (GKE). If you want
to containerize your apps while staying focused on building your solutions and not how to
create or maintain Dockerfile
s, Cloud Buildpacks is for you.
In the last video, we showed developers how to containerize a Python
2 Cloud NDB app as well as a Python
3 Cloud Datastore app. We targeted those specific implementations because Python 2
users are more likely to be using App Engine's ndb
or Cloud NDB to
connect with their app's Datastore while Python 3 developers are most likely using Cloud
Datastore. Cloud Buildpacks do not support Python 2, so today we're targeting a slightly
different audience: Python 2 developers who have migrated
from App Engine ndb to Cloud NDB and who have ported their apps
to modern Python 3 but now want to containerize them for Cloud Run.
Developers familiar with App Engine know that a default HTTP server is provided by default and
started automatically, however if special launch instructions are needed, users can add an
entrypoint
directive in their app.yaml
files, as illustrated below. When those App Engine apps are containerized for Cloud Run,
developers must bundle their own server and provide startup instructions, the purpose of the
ENTRYPOINT
directive in the Dockerfile
, also
shown below.
Starting your web server with App Engine
(app.yaml
) and Cloud Run with Docker
(Dockerfile
) or Buildpacks
(Procfile
)
In this migration, there is no Dockerfile
. While
Cloud Buildpacks does the heavy-lifting, determining how to package your app into a container,
it still needs to be told how to start your service. This is exactly what a Procfile
is
for, represented by the last file in the image above. As specified, your web server will be
launched in the same way as in app.yaml
and the
Dockerfile
above; these config files are deliberately juxtaposed to
expose their similarities.
Other than this swapping of configuration files and the expected lack of a
.dockerignore
file, the Python
3 Cloud NDB app containerized for Cloud Run is nearly identical to the Python
3 Cloud NDB App Engine app we started with. Cloud Run's build-and-deploy
command (gcloud run deploy
) will use a
Dockerfile
if present but otherwise selects Cloud Buildpacks to build
and deploy the container image. The user experience is the same, only without the time and
challenges required to maintain and debug a Dockerfile
.
If you're considering containerizing your App Engine apps without having to know much about containers or Docker, we recommend you try this migration on a sample app like ours before considering it for yours. A corresponding codelab leading you step-by-step through this exercise is provided in addition to the video which you can use for guidance.
All migration modules, their videos (when available), codelab tutorials, and source code, can be found in the migration repo. While our content initially focuses on Python users, we hope to one day also cover other legacy runtimes so stay tuned. Containerization may seem foreboding, but the goal is for Cloud Buildpacks and migration resources like this to aid you in your quest to modernize your serverless apps!