In this session, we’ll be taking you through three short demos that will help you
when working with Google Cloud serverless technologies.
We’ll be showing you how to use buildpacks to build containers,
how to use Cloud Code to deploy Cloud Run services,
and how to use Visual Studio Code to debug Cloud Functions.
Hi, I’m Katie, and in the next few minutes
you'll see that building containers isn't that scary.
When working with serverless,
you have to work with a packaging concept known as a container image.
Container images, or just containers, are just that.
They contain all the elements required to run an application.
They allow an app to run in isolation
and for many apps on the same infrastructure to run without interfering with each other.
There are multiple ways that you can make these containers.
The most popular way is to write a list of instructions
in a Dockerfile that are used to build your image.
You start from a base-image,
you copy files from your local file system into the image.
You then run commands such as installing dependencies,
and you then define a entrypoint,
a command that is run when you start your container.
This is a very common template for Dockerfiles,
so much so that there are now automation tools
that presume this format.
With buildpacks you don't have to write a Dockerfile.
Google Cloud Buildpacks are built onto Buildpack standard,
automatically detecting which programming language
you're using and running the steps common for that language
and make a container ready to be used across many Google Cloud products.
In fact, most Cloud Functions deployed in the last year have been using buildpacks
behind the scenes, with help from the Functions framework.
Sara will be discussing more about Cloud Functions later in this demo.
Let me give you an example of the power of Buildpacks.
When developing a JavaScript app on your computer,
you would install Node, write your app, and create a package.json file
where you define your dependencies and your start command.
You would then install the dependencies that you've defined,
and then you would run the start command you’ve defined which will start your web app.
If you were to write a Dockerfile, you would do the same thing.
You'd start with a Node based image which has Node already installed for you.
You then copy your files, then install your dependencies,
and when the container is invoked, run your web server.
Buildpacks do the same thing when they detect a Node app.
It will detect that you need the Node runtime and set that up for you,
copy your files into the image,
Install your dependencies, and then set the entrypoint to run
when your container is started.
However, for some programming languages, there may not be one way to do things.
For example, when developing in Python, installing dependencies is very standard,
but how to start your web server is not.
Buildpack doesn't know what to do in this situation
and will return an error if you try to build your container
without defining your entry point.
In this case, Buildpacks needs one added file: a Procfile or process file,
that defines what you want the web process to be.
Adding this file to your code base
tells Buildpacks what you want to run to start your web server.
It's picked up by the build process,
and will be run when you start your container.
No matter the language you use, you can set your own Procfile.
For instance, the Java Buildpack doesn’t require a Procfile
but you can still define one.
Defining a Procfile will override the default command RUN
to start your container.
You can also override other default functionality with environment variables.
Take a look at the documentation over on GitHub for more information.
After installing the Pack command tool,
you can build your containers on your local machine
if you have Docker installed.
Or you can submit the build
to Google Cloud Build, which will run Pack for you
making your containers available in the Google Container Registry.
Buildpacks are available for JavaScript, Python, Java, .NET, and Go.
You can read more about this on our blog
and try out some sample applications over on GitHub.
But as for deploying your containers, let me hand you over to Abby.
What Katie just showed with Buildpacks was awesome,
but what's next?
Hi, I'm Abby.
And I’m going to show how one DevTool makes containerizing
and deploying your app to Cloud Run,
one of Google Cloud’s serverless offerings, easy.
But first, what is Cloud Run?
Where am I deploying to?
Cloud Run is a fully managed serverless, container-based platform.
It lets you deploy stateless HTTP containers.
Deploying Cloud Run services is super fast, and I'll show you my demo in a bit.
You also get the flexibility of configuring your own custom domains.
Cloud Run supports custom binaries, so any language or library is fair game,
and because it's container-based Cloud Run services are portable.
One of the biggest appeals of Cloud Run is the ability to scale down to zero
when no traffic is hitting your service.
Cloud Code can help you out on your serverless journey right from your IDE.
Cloud Code is an IDE plugin that automates development workflows
for cloud-based applications written in Python, Go, Java, Node.js, and C#.
If you develop with VS Code
or one of these JetBrains IDEs, Cloud Code can help you out.
Cloud Code supports a number of development flows for Cloud Run.
First, it helps you ramp up fast with integrated samples.
When it comes to building and deploying container images,
Cloud Code merges the two steps into just a couple of clicks,
and regarding debugging, Cloud Code lets you debug your service
in a local emulated production-like environment.
Cloud Code also has a feature where after hitting Save,
your code is automatically built and deployed again,
speeding up your inner dev loop.
And finally you can manage your Cloud Run services right from your IDE.
That’s a quick look at Cloud Run and Cloud Code, but how about demo?
With Cloud Code I'll create a starter Cloud Run service
and run it locally on the Cloud Run Emulator and finally deploy it to Cloud Run,
all from my IDE.
So I’m using VS Code for this demo.
I already have Cloud Code extension installed from the VS Code marketplace.
You can tell because I have this stack of four icons seen to the left
and a Cloud Code button down here.
I’ll create a new project using one of Cloud Code’s integrated samples.
First I’ll hit the Cloud Code button, then select a new Application,
and then Cloud Run application.
Cloud Code has samples for the supported languages I mentioned.
For this demo, I’ll create a Node.js Hello World service.
I now have a Node.js Cloud Run service that's ready to be deployed.
Before deploying the Cloud Run,
I want to make sure everything works locally first, though.
To do that, I'll build and deploy locally to Cloud Code Cloud Run emulator.
It emulates productions so there aren't any surprises
once I actually do deploy the production.
I’ll hit the Cloud Code button again and select Run on Cloud Run Emulator.
Now I'll configure my local deployment.
For my builder, I’ll switch from Docker to Buildpacks
so that I don't have to worry about Dockerfile.
Under Advanced Service Settings,
I can set container properties like CPU allocation,
Environment Variables and connect to Cloud SQL databases.
Looks good.
Now, I'll hit Run.
Cloud Code is now handling all the commands for a building and deploying to the emulator.
Once that's done, I can open this link and there it is.
My Node.js service built with Buildpacks, running locally in my emulator.
Since everything is looking great, I'll skip debugging things
and jump right to deploy this service to Cloud Run.
I will hit the Cloud Code button one more time
and select Deploy to Cloud Run.
This all looks very similar to deploying to the local emulator.
Since I'm creating a new service, I'll leave this box alone.
My deployment platform will be Cloud Run
and I'll, once again, switch my builder to Buildpacks.
And then I'll hit Deploy.
I'll click the link to my deployed service.
And this is my Node.js service deployed to Cloud Run.
Now anyone can access it.
That was a look at Cloud Code makes building containers
with Buildpacks and deploying to Cloud Run easy.
Join the Cloud Code channel on the Google Cloud Platform community Slack
to stay up to date on announcements and ask questions.
Now, I’ll hand it off to Sara
who's going to cover Local debugging of Cloud Functions.
Thanks, Abby, for showing us how you can use Cloud Run within Visual Studio Code.
Hi, I’m Sara,
and I'm your guide to another serverless compute offering
called Cloud Functions.
Cloud Functions allows you to run small snippets of code in an event-driven way.
So let's see Cloud Functions in action.
Suppose you have previously deployed a Cloud Function
that receives data from an IoT sensor
that reports about whether the temperature is too hot or it’s okay.
Let’s say that you want to verify your function
is working properly in production.
You can use Visual Studio Code
and the terminal window to send curl commands.
So here we can send a curl command to verify whether the temperature is too hot
and your choice if this is Celsius or Fahrenheit.
And here, when we send this command we see that it reports back to hot.
We could also test the Okay condition and we see it comes back, Okay,
but what if you forget to send a payload?
Notice that it also also says Too hot.
You have found a bug.
Now you want to fix and verify this locally before you push to production.
And to do that you can use the Functions Framework.
So the Functions Framework is an open-source
functions-as-a-service framework, written by the Google Cloud Functions team.
And the Functions Framework is available in Go, Java, PHP
Python, Ruby, and .Net.
And here you can see that has been successfully installed.
And we can also use Visual Studio Code's
built-in debugging tools for Node to debug our file function.
Since we're in debugging session
we want to hit Continue to allow the function to just finish gracefully.
And now we can go to the first terminal window and stop serving the function.
Let's say that the specification says in the unlikely event
that a payload is not sent, we want to throw an exception.
So I’ll add the code now to throw the exception and let’s test this.
But this time I am not going to use the inspect flag.
This will not start a debugging session.
And you notice that VS Code stays
in the blue status bar and let’s invoke the function.
And we see the correct behavior.
The exception is thrown, and it’s also locked.
Now, you are ready to deploy your function to production.
If you would like to learn more about how to do this demo yourself,
you can check out the corresponding code lab for this talk.
Thank you for attending our session.
You saw how to use Buildpacks, build containers,
how to you use Cloud Code to deploy Cloud Run services,
and how they use Visual Studio Code to debug Cloud Functions.
If you want to learn more, you can visit our GitHub repo for Buildpacks.
Check out the Cloud Code channel in the Google Cloud Platform community Slack
and follow along debugging Cloud Functions in our codelab.
Thanks for attending, and have a great Google I/O.