MARK PELLEGRINI: Hi, I'm Mark.
JOHN ASMUTH: And I'm John.
MARK PELLEGRINI: We're both engineers on the Google Cloud
SDK team.
Today we're going to be giving a brief walk-through of the Cloud
SDK and specifically the new gcloud command-line tool.
JOHN ASMUTH: Here at Google we've
been working hard to create a great Cloud Platform.
And we know that for a lot of you
this means a great command-line experience, too.
MARK PELLEGRINI: The Google Cloud SDK
gives you everything you need to work with the Google Cloud
Platform in a single convenient package.
The new gcloud tool is a complete rewrite
of the existing Cloud command-line
interfaces you might be aware of, with a specific focus
on product integration, ease of use,
and, of course, command-line power.
The best way to show off what gcloud can do
is just to show you.
JOHN ASMUTH: Let's start with a situation
we've all been in being a new developer on a project team.
You're an experienced developer and you know how to code
but you don't know the tools your team uses,
the workflows they follow, or how to get started.
Fortunately for us, this app is built on the Google Cloud
Platform.
Your new tech lead tells you to go grab the Google Cloud
SDK, that your project name is gcloud-demo-io2014,
and that there's a bug in production that
needs to be fixed right away.
MARK PELLEGRINI: We don't really know where to start,
so we search for the Google Cloud SDK.
And we land at Google's Developer site,
where we see some installation instructions.
JOHN ASMUTH: The set up looks pretty easy.
Run one command to install.
And then run gcloud off login on the command-line.
MARK PELLEGRINI: We've created this one liner that
can take care of the whole installation process.
If you're on a system with bash, paste it into a terminal
and follow the instructions.
Follow the prompts to choose some installation options.
And it will then download and install
the latest version of the SDK.
OK.
So we have the Cloud SDK now.
The website said it installed the gcloud tool.
That seems like a good place to start.
JOHN ASMUTH: If we run in gcloud with bashh
it's going to tell us about all the things we
can do with gcloud.
The developer site's instructions
mentioned running gcloud off login.
So let's do that first.
When you run that command it will take you
to an authentication page where you authenticate
with your Google account.
And then you can give gcloud permission
to work on your behalf.
MARK PELLEGRINI: OK.
Now we're logged in, but we don't really
know what to do next.
Let's see if there any other gcloud commands that look
promising.
There's a init command.
It sounds like that'll set up a local workspace for us.
Looks like it needs a project.
But we have that information.
JOHN ASMUTH: gcloud init is a command
that can set up a local development environment for you
and bring in a repository hosted by Google.
After the init finishes, there's a directory
holding the project's gear repository
with all our project files.
Now that we have all the code, we
need to get work on fixing this bug.
MARK PELLEGRINI: First, let's try
to reproduce it with the current code.
We need to run this app to see where the problem is.
I know we run this app on App Engine.
I bet there's a command in gcloud
for running an App Engine app.
Well, it looks like there's an app group.
That seems promising.
Great.
There's a run command.
Let's try that.
Looks like we need to give it our project directory.
JOHN ASMUTH: gcloud app run will run your app in a local testing
environment on your own computer without receiving
any real traffic from the internet.
Hey, it looks like it's running.
Let's check it out.
Sure enough, there's a problem.
This stack trace looks pretty obvious though.
Let's try and fix it.
MARK PELLEGRINI: So first, let's take a look at our source.
Well, I see what's wrong here.
How did this get into production?
One of the nice things about the local app server
is that it will automatically reload your source
if it changes.
If we just refresh the page we can see if our fix is good.
JOHN ASMUTH: Looks like it's working now.
Now it's time to get this fix submitted.
Since we're using Git, we can use all the normal Git commands
and commit our change and then push it back
to our project's repository.
You can also configure your project
to deploy the app when you push, but for this project
and for this demo, we haven't enabled that feature.
MARK PELLEGRINI: Instead, let's use
gcloud to redeploy the app since it's currently
broken in production.
We need to tell it what version to deploy to.
Once the deployment is finished, we
can check on the production site to see our fix in action.
JOHN ASMUTH: That's pretty easy. gcloud
had everything we needed to set up a local development
environment, make a fix, test our app,
and then redeploy back into production.
The unified command-line and integrated help
really helped us figure out the right path
to take to get where we needed to go.
MARK PELLEGRINI: All right.
Let's say now that we work in DevOps,
and we're responsible for deploying a web application
across a farm of machines.
How can gcloud help us do this?
JOHN ASMUTH: First, let's just start
with a bunch of empty VMs.
We just created them so they're running Linux,
but they have nothing else on them.
We want to have our web application running on each one
and then set up a load balancer to distribute traffic
among all of them so we can increase our overall capacity.
MARK PELLEGRINI: We use gcloud to push the files for a custom
web server to each machine and to get it running.
When we're done, we'll have our server
running on a fleet of machines serving traffic
through a single IP.
We can probably configure each VM manually
but there's a lot of them and it would be really handy
if we can just script this.
Let's drop back into the command-line
and see how to do this using gcloud.
JOHN ASMUTH: First, let's find the VMs
that we already have running.
We can get some basic information about our cluster
by running with a list command.
It shows us the instance name and IP among other things.
For this demo, we only have a couple,
but really if there's any more than one
we'd probably want to script this.
Since the commands can also get long sometimes,
we added a shell mode to gcloud.
Here we'll just run gcloud compute --shell,
and every future gcloud command can omit the first two words.
MARK PELLEGRINI: Next, we'll create a target pool that
will refer to each of those VMs.
A target pool is simply a grouping
of machine between which the load
balancer can distribute traffic.
For the instances to use, I can just
give it the output of the other command that lists all of them.
Once the target pool is ready we can create a forwarding rule.
A forwarding rule accepts traffic on one IP
and does some basic load balancing
between the VMs in the pool we just created.
OK.
Forwarding rule's set up.
JOHN ASMUTH: Let's see what IP we
need to connect to by listing the forwarding rules available.
Then we can use cURL to connect to the web server.
Of course, this isn't going to work because there's
no actual software running on that machine yet.
MARK PELLEGRINI: Fortunately, we've
got a nice little Go program that will serve HTTP.
It's pretty simple.
All it does is it tells you the host name of the machine
that it's running on.
We're using a Mac here but the program
can easily be compiled for Linux.
JOHN ASMUTH: Now we need to push our server to all the VMs.
We can use SSH and SCP just like normal,
but gcloud can even make this a bit easier.
The config SSH command will create an alias
in your host file for each of the available VMs
so that you can easily SSH to all of them
without having to remember their IP addresses.
Here we'll use bash in an environment variable that
will hold each of our VM names.
Then we can use bash to make a for loop that
will run SCP and send our server to each
of the VMs in our project.
Look at them go.
Then once that's all set, we can use the same variable
and another for loop-- very similar-- to iterate
over each VM and use SSH to connect and run nohup
and sudo that will run our server in the background.
MARK PELLEGRINI: Of course, the firewall
doesn't have anything open by default.
So we have to ask for an exception for these machines
so that they can actually receive HTTP traffic.
We use gcloud to indicate that these machines will
be used as HTTP servers and that port 80 should be opened.
Since we're making an API call for each instance
we issue these commands in parallel to save some time.
JOHN ASMUTH: Now if we make a few cURL requests to the load
balancer, we can see that it's all working
and the traffic's being split between our VMs.
MARK PELLEGRINI: So just like that, we've
set up a load balancer pool of machines serving our web app.
Of course, this is just one example
of the many powerful things that gcloud command-line tool
can do for you.
Check out our developers page to read more
about the services we support or just
give gcloud a try on your own.
JOHN ASMUTH: And we're continually
releasing new features.
So also be sure to join our Google
group to get the latest updates.
MARK PELLEGRINI: Thanks.