DEV Community: Abby Carey

Getting serverless with Python and Cloud Run

Abby Carey — Fri, 02 Oct 2020 19:09:05 +0000

On this edition of Serverless Expeditions, we take a look at how to deploy a Cloud Run service written in Python.

Check out the video version of this blog post.

Source code for this blog post is available on GitHub.

GoogleCloudPlatform / serverless-expeditions

Managing the resources for an app can be a challenge. Deploying your app in a serverless fashion is popular because it helps take care of that for you. Cloud Run is fully managed, meaning you don’t have to worry about infrastructure scaling as traffic changes. Since it’s container based, you can also use any language and framework. An added bonus is that you can redeploy with just one command.

Let’s say you and your friends are planning a foreign wine night. Most of the shops your group want to order from are in the EU and family owned. Their online stores don't display your country's currency (USD).

To get an accurate gauge on price, a unit conversion service that converts Euros to USD can be made and deployed to Cloud Run with Flask. Flask is a popular framework for creating Python web apps because it’s lightweight and easy to set up.

Your Cloud Run service has the basics:

An html file where a form gets user input.

A simple css file.

And an app.py file where functions and routes are defined.

For the full source of this project, check out our repository on GitHub.

Once you’ve created your service, Cloud Run only needs one extra file for deployment. No code changes needed.

This is the Docker file. Here you customize the runtime of your container to suit your needs exactly. Containers are a way to isolate your service to make it run the same no matter where it’s deployed.

Taking a closer look…

FROM specifies a base Docker image, the Python runtime.
COPY adds files from your computer's current directory to a directory inside the container.
RUN installs Flask ,Gunicorn, and our currency converter's dependencies.
CMD is a command that starts your app inside the container and binds it to a port. App:app means import the app from the app.py file.

If you want to run a different version of Python, it’s no big deal. With Cloud Run you can run any version of Python you want as long as there’s a Python base docker image available for it.

With Docker file in hand, you can now kick off your first deployment. You first build a container with Cloud Build. This bundles up your code along with everything you’ve added in your Docker file and pushes it to the Container Registry. Container Registry is where your container images are stored. Finally, you deploy the service to Cloud Run.

All this is handled with just two commands. From your terminal, run the following commands to build a container image and deploy the service using that image.

$ gcloud builds submit --tag gcr.io/PROJECT_ID/euro-to-usd

$ gcloud run deploy --image gcr.io/PROJECT_ID/euro-to-usd
--platform managed

And that’s it! Your Cloud Run service is now deployed.

Going to the Cloud Run section of Google Cloud now shows your deployed service and its URL.

Here you also have access to important metrics and the Revisions tab, where you can easily redirect and split traffic to different versions of service if you’ve deployed it more than once. This is handy if you discover a breaking change and want to temporarily roll back.

But what if your friends hit an error when trying your service out? How could you figure out what’s going wrong? That’s where Cloud Monitoring comes in.

Cloud Run has a Logs tab where you can see everything being logged by your service.

To dig a little deeper, there’s Error Reporting. Here we see a value error was triggered on line 20.

After taking a look at the stack trace, making a quick fix, and redeploying, you now have a working app to share. Goodbye Euros, hello USD!

Now, with correctly calculated wine prices, the whole group is ready to buy fancy wine that fits their budget.

About Serverless Expeditions

Serverless Expeditions is a fun and cheeky video series that looks at what serverless means and how to build serverless apps with Google Cloud.
Follow these hosts on Twitter at @abbyapplebees and @martinomander.

Creating a cloud-based Pokédex: Local testing with Cloud SQL Proxy

Abby Carey — Thu, 09 Jul 2020 15:56:07 +0000

Previously in this series, I went over what I used to build my first Python web app. In this post, we're taking a look at how to locally test a Flask app with Cloud SQL Proxy.

Locally testing a Flask app that's connected to a Cloud SQL instance can be a little tricky. It's not as simple as calling python3 main.py.

As an example, let's walk through creating a Cloud SQL instance and testing my Pokédex project locally.

Clone my repo to get started.

abbycar / pokedex-project

A look at Cloud SQL Proxy

Cloud SQL Proxy allows you to locally communicate securely with your Cloud SQL instance.

The proxy handles data encryption to and from your database using Transport Layer Security (TLS). If you're not familiar with TLS, you can see it in action as the padlock in your address bar. SSL certificates establish authority, verifying client and server identities.

It also handles authentication with Cloud SQL, removing the need to provide static IP addresses.

When you eventually deploy your app to App Engine, your app uses the Cloud SQL Proxy that’s built in to the App Engine environment.

When testing things locally, you need to download your own copy of the Cloud SQL Proxy.

Enable Google Cloud products

Since this app uses Google Cloud Platform (GCP) products, we need to create a GCP project.

Get access to GCP by creating a new project with billing enabled. If this is your first time trying out GCP, you can start a free trial.

You also need to install the Google Cloud SDK and enable the following APIs:

Once you’ve done all that, open a terminal and enter the following command to get credentials for authenticating with GCP services.

$ gcloud auth application-default login

Create a MySQL Cloud SQL instance

Let’s start by creating a second generation MySQL instance in your terminal.

The following command takes a few minutes to complete. Check up on the creation status at the instances page.

$ gcloud sql instances create <MY-INSTANCE> --root-password=<ROOT_PASSWORD> --database-version=MYSQL_5_7 --region=us-central

Now that you have an instance, add a new database named pokemon. This is where we store all pokemon and user info.

$ gcloud sql databases create pokemon --instance=<MY-INSTANCE>

Your new database now shows up in your Cloud SQL instance.

You can connect to your database with your root user account and password. Optionally, create a new user. A host set to % means the user has an unrestricted host name.

$ gcloud sql users create USERNAME \
    --host=% --instance=<MY-INSTANCE> --password=PASSWORD

Connect to your database with Cloud SQL Proxy

Open a terminal at the sample code folder and download an executable Cloud SQL Proxy with the following commands. For non-linux commands, check out the Cloud SQL Proxy quickstart.

$ wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy`

$ chmod +x cloud_sql_proxy

Run the proxy and connect to your instance. You can find your instance connection name here.

./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306

Keep the Cloud SQL Proxy running in the current terminal and continue along in a new one. Without this connection, the app won’t be able to retrieve data from the pokemon database.

Configure your environment

For local testing, update your config.py. It’s best to store these variables as environment variables in app.yaml, however, app.yaml variables aren’t reflected until deploying to App Engine. I’ll go over app.yaml and the deployment process later in this series.

A hot new product Google Cloud added recently is Secret Manager. You should check it out if you want to store sensitive info in the cloud instead of in a file in your code.

Create a virtual environment

Since the Python packages and modules you’ve installed probably aren’t the same as what my app needs, a virtual environment gives my app the perfect place to run.

To get one up and running, enter the virtualenv command and activate it.

$ virtualenv -p python3 venv
$ source env/bin/activate

You should now see (venv) next to your file path in the terminal.
Now install the necessary packages and modules.

$ pip install -r requirements.txt

Load MySQL data with a .csv

Since the database is currently empty, testing my app now will fail.

In my repo I have all pokemon data stored in the pokemon-db.csv file. Use this to initially populate the database.

Call the following command to create your relational tables. At this point they’ll be empty and ready for some data.

$ python3 pokeview/models.py

In a new terminal, connect to your MySQL instance and load the provided pokemon-db.csv file. Your Cloud SQL Proxy must be running in a different terminal for this to work.

$ mysql -u username -p --host 127.0.0.1 

LOAD DATA LOCAL INFILE 'pokemon-db.csv' INTO TABLE pokedex FIELDS TERMINATED BY ',' LINES TERMINATED BY '\r\n' IGNORE 1 LINES

After loading the CSV, your pokedex table should now have the original 151 pokemon in it.

Run it!

It’s time for all that setup work to pay off!
Run your app to start up a local webserver.

$ python3 main.py

In your web browser, go to http://localhost:8080 where the app is running. The port is configured via the main.py file.

Getting around API timeouts with Cloud Functions and Cloud Pub/Sub

Abby Carey — Wed, 20 May 2020 16:21:49 +0000

Recently I was pitched a revolutionary Slackbot idea. What if, with the power of Cloud Functions and Cloud Vision, I could take any image and dogeify it?

An image run through my Slackbot

In this post, I'll show you how I built a Slackbot with Python that does exactly this. In addition, I'll show you how to overcome a common issue when working with APIs and how a unique Cloud Functions pattern can help you overcome this obstacle.

The timeout problem

My slash command Slackbot consisted of one Cloud Function, doge-response. When someone types /doge in their Slack client, Slack sends an HTTP event that triggers my Cloud Function with the text the user typed after my command. This text should be an image URL to dogeify.

The data flow looked like this:

Unfortunately, when it was time for testing, my Slackbot would think about things for a bit and return an operation_timeout error.

Ugh.

Timeouts are a problem for many services. Some give you 5 seconds, some even more, but in the end it sometimes isn’t enough for what you want to do.

After some research, I learned that Slack only gives you three seconds to respond to a slash command. Three seconds isn’t enough time to run a large image though Cloud Vision, create a new image, overlay Cloud Vision labels, and upload that image to Cloud Storage.

How did I get around these pesky timeouts? The solution is to get asynchronous, which wasn’t as hard as I thought it would be. By sending messages between multiple Cloud Functions, I was able to avoid API timeouts entirely.

Two Cloud Functions are better than one

The first step towards an asynchronous Slackbot was to split my single Cloud Function into two.

To facilitate messaging between these two functions, I tied in Cloud Pub/Sub. Cloud Pub/Sub is a real-time messaging service that allows you to send and receive messages between independent apps.

Cloud Function 1: doge-queue

Triggered by HTTP from /doge slash Slack command.

Verifies that the request is good
Publishes the contents of the Slack response to my Cloud Pub/Sub topic, doge-convert
Returns a “Working on that” message back to the Slack channel

Cloud Function 2: doge-response

Triggered by Cloud Pub/Sub publishings to the doge-convert topic.

Decodes the Cloud Pub/Sub event data and now has the contents of the Slack request
Dogefies the image
Sends the image back to the slack channel where it was called using the response_url attribute of the Slack request

In the doge-queue Cloud Function, publishing one message to Cloud Pub/Sub takes less than 3 seconds, giving me time to send a response back to the Slack channel.

Much better than a timeout!

This message buys me 30 minutes to respond back to the Slack channel. While 30 minutes is awesome, I also need to think about other timeouts that could arise. Cloud Functions itself has a default timeout of one minute, which is plenty of time for what I need to do. If I needed more time, I could have updated my Cloud Function’s timeout to be up to 9 minutes.

Gettin’ Cloud Pub/Sub with it

After setting up a my Cloud Pub/Sub doge-convert topic and creating a pull subscription for doge-response, it was time to connect the dots between my two Cloud Functions.

In my doge_queue function, I dumped the contents of the Slack request into a JSON object.

publisher_client.publish() then takes my topic path and the JSON object (encoded), publishing it to my topic.

By assigning publisher_client.publish() to a variable, future, I can check the future.result to confirm the message was published successfully.

At this point, a message sent with my Slackbot is now in my doge-convert topic. Once that message hits the topic, doge-response is triggered by the event.

In my doge_response function, I grab the data out of the event and decode it.

With just one line of code, I now have the contents of my Slack request to work with in my second Cloud Function.

Conclusion

And that’s it! By having my first Cloud Function send an initial message back to Slack while it publishes the contents of the Slack request to Cloud Pub/Sub, I buy my second Cloud Function plenty of time to do all the heavy lifting. Goodbye 3 second API timeout limitation!

If you want to see all the code for this Slackbot, including how I handled image storage, called the Cloud Vision API, and handled text overlay, check out my GitHub repo!

abbycar / doge-a-chat

A Slackbot that receives an image as a slash command and returns it back in Doge meme format.

Creating a cloud-based Pokédex: overview

Abby Carey — Tue, 28 Jan 2020 17:39:22 +0000

This blog series details what I learned on my Python 3 app development journey and the roadblocks I hit along the way. In this post I give an overview of a Python 3 app I created using Flask and a variety of Google Cloud Platform (GCP) offerings.

If you’re new to Python 3 web app development, you’ll quickly learn that you have a lot of choices to make. You might ask yourself:

Is there a preferred framework?
How do I handle user authentication?
How do I show the world my app?

These are the same questions I asked myself. As with many questions in life, the answer is “It depends”, but you can take out the guesswork by building from a credible sample.

The final result

For my first Python web app, I decided to create a simple Pokédex. It includes the following features:

Data displayed from a Cloud SQL database
User account creation and persistent sign in
A Pokédex for each user
The ability for users to toggle and store the catch status of pokémon through POST requests
Automatic scaling with App Engine once deployed

Here’s the final result deployed to App Engine. Log in with my test account to scope things out.

Username: test
Password: testtest

It’s not too pretty or feature packed, but feel free to “catch” some pokémon by clicking on the pokéballs!

Check out the code on GitHub

abbycar / pokedex-project

Get rolling with starter code

Choosing what technologies you want your app to use is hard. I find learning new concepts easiest when building off existing projects. I tried a handful of tutorials that used a variety of technologies before settling.

I got my bearings with the Python + MySQL bookshelf example. Note that since starting this project the docs and code sample have changed. You can see a snapshot of the docs I used here.

I chose to build off this project because it had the bones of what I wanted to do. The choice of tech was handled for me. All I had to do was trim some fat and slap a bit o’ muscle on it. A fair bit of tweaking was involved to get where I wanted to go, but in the end you’re learning from a (hopefully) credible source on what a good app looks like.

The app I created utilizes the tech listed below. Note that I’ve chosen to use Google Cloud products for this sample. AWS and Azure have similar offerings.

Flask and Jinja2

When it comes to my apps, I hate boilerplate code. I want to get my app up and running without an additional 1,000 lines of code clogging things up.

To limit this in my app, I picked Flask as my framework and Jinja2 as my templating engine. Both add hardly any boilerplate to my app.

Flask is a light-weight Python web framework that’s great for beginners because out of the box you get the basics of what you need. If you find yourself needing other features like user sign in and database management, just install an extension.

By default, you need to install the Jinja2 template engine to use Flask.

Sticking with Jinja2 was an easy choice for me since I didn’t want boilerplate code and because I didn’t choose Django as my Python web framework.

Why no Django?

Django is another popular route to go, but I know that my app will stay relatively small. I don’t need all the bells and whistles it offers. Also, Django apps are usually monolithic in nature.

Flask puts an emphasis on microservice based architectures and modularity, making it better for beginners. While my app doesn’t have microservices, it does have Blueprints which provide separation of operations at the application level, and share one app config.

Cloud SQL and Cloud Storage

I wanted all my app’s content to live in the cloud. Google Cloud in particular.

Cloud SQL for MySQL is a fully-managed database service that makes it easy to create and manage MySQL relational databases instances in the Google Cloud Console.

It also supports secure external connections and local development with the Cloud SQL Proxy.

Cloud Storage was something I didn’t know I needed until I learned about hotlinking. Hotlinking (also known as bandwidth theft) is when you display static assets (such as images) on one website that are hosted on another website.

To be respectful of others web resources, I downloaded what I needed and stored it in a Cloud Storage bucket. This gives me full control of my resources.

SQLAlchemy

SQLAlchemy is a database toolkit and object-relational mapper (ORM) implementation. It provides an interface for creating and executing database-agnostic code without needing to write SQL statements. For my example I chose to go with MySQL, but I could’ve picked PostgreSQL or MongoDB and used the exact same code I’ve written in my app.

Not having to write SQL statements is a pro if you’re a SQL beginner. However, you do need to have a good grasp of query logic to use SQLAlchemy statements.

App Engine

App Engine is one of GCP’s web hosting options. App Engine automatically handles scaling my app’s network resources up and down depending on how many requests are hitting my app.

It’s a good fit if you don’t want to think about the nitty gritty of load balancing.

In the end my app has the following structure.

Stay tuned for the next part of this series. We’re going over how to locally test Flask apps with Cloud SQL Proxy.