Demo: Introduction to Waypoint

Transcript

So I spent a lot of time talking about what Waypoint is and why we built it, but I want to dive in and show you how this thing works. So let's do that now.

Context

To start showing you this demo, we're going to show you the context that Waypoint has. Context lets us talk to different Waypoint servers. In this case, we have a local environment that we're running to test our deployments and a production environment that we might be sharing across our company.

Configuration File

Every project that you have has a Waypoint configuration file. The project maps one-to-one to a Git repository or VCS repository. In this case, we named the project HashiConf Demo, and we have one application that we want to deploy within this project. To do that, we're going to be using Docker to begin. You can see the demo here, our app, and then our build and deploy settings.

Docker File

Next, let's take a look at the Docker file that we will be using to build our application — in this case, it's a standard React-based application, so we're going to build the application with React and then serve it using Nginx.

With all these configuration files, first of all we have run a waypoint init. A waypoint init registers our project with the Waypoint server. It also validates our configuration, makes sure that we have all the plugins, and that we're authenticated properly, etc. Once the waypoint init is done, we could run the up. As the up is running, you can see we build the image and show you that output. We do the deploy, and we do a release.

To remind you again, this is all happening against Docker — against our local deployment currently. This might be to test the build, test the deploy, make sure it works. Once the release is done, we get a URL at the end of it. If we click that URL, we could see it worked, everything deployed, and it's running.

Deploying into Production

Everything worked locally. Next, we're going to switch to our production context. Let's deploy this application into production. To show that things are changing, we're also going to modify the application. I’m going to un-comment some stuff that we have here in our application so it looks a little different.

We’re also going to modify the Waypoint configuration. In production, we're not going to be using Docker directly. We're still going to use Docker to build the image, but we also need to push the image of the build to a registry so that our deployment platform can reach it.

We're going to use a Docker registry and push to that. Then for the deployment, we're going to use Kubernetes in production. Use that plugin — Kubernetes has slightly different configurations — so we're going to do some of that. We're also going to set up a release manager in this case, and that'll make sure that we could visit this publicly. We run the init process again. This is done to ensure that we switched servers, so we need to make sure that this project is again registered with the new server.

Then we run waypoint up once again. In this case, it'll look a little different. The build looks the same because we're still using Docker, but we're going to see a push happen afterward. Then we're going to see the deploy and release look different because we're going to Kubernetes this time and not Docker, and they work differently. But at the end of it, we get a release URL, we get a deployment URL. Let's go ahead and look at that.

It deployed. It looks different because we modified our application, but it's running on Kubernetes and using the exact same configuration style and the exact same waypoint up workflow.

Deploying to Serverless

To show the flexibility of Waypoint one more time, we are now going to modify the application because we're going to deploy it to a different platform. We're going to deploy to a serverless platform this time.

Let's modify the application and add in a little bit more so it looks different. We're going to add in this timeline component. Let's change it from a dark theme to a light theme, so it'll definitely look different this time. Next, we're going to modify our Waypoint file again. In this case, we're going to be targeting the Azure container service. So, let's throw away the Kubernetes configurations and add in the Azure container configurations.

We use the Azure container instance plugin. This has a number of different configurations — you can see we need a resource group here and capacity config. It looks a little bit different, but the workflow will be the same.

With that saved, we can run waypoint up again. We don't need an init this time because it's the same server that we're using. The deploy and release will look a little different because we're going to ACI this time and not Kubernetes.

At the end of this, we're going to get — again — two URLs out of it; the application URL and the deployment URL. If we open that, we now see our light mode Waypoint website with our timeline component rendered there. This is now running on ACI.

Demo Recap and Summary

We showed three different deploys, one locally on Docker, one in Kubernetes, and one in ACI. Throughout the whole thing, it required minimal changes and running waypoint up again. We talked about exec and logs, so let's also look at that. If we run waypoint exec /bin/sh, we get a shell. This shell is running in ACI. This is a feature that ACI doesn't provide natively. This is showing how Waypoint could provide features like this that the platform may not support. It's a real shell. We could prove that by cat-ing our Nginx configuration that we built into our image — you could see that is there.

We can also take a look at logs — let's run waypoint logs. We could see all the various HTTP request outputs that we would see because we visited the application.

Let's finally look at the UI. So we did all this, we've been working in the terminal this whole time. Let's open up the UI. You can do that simply with the Waypoint UI command. Since our Mac, in this case, is in light mode, our UI is also in light mode. You could see here; we have all our builds, all our deploys listed here. You saw some logs, but you could also see it from the UI. The UI gives you a great way to get an overview of everything that has been happening with this Waypoint server.

On the deployments page, you could also see on the right here that for each deploy, we have that deployment URL. I mentioned earlier in the keynote that every single deploy gets a version URL — so we have V1 and V2 here. They have the same name, the globally communal fox, because they're the same application. But they get the V1 and V2 because they're different deploys.

Here I want to click each of them because — if you remember — one is on Kubernetes, and one is on ACI, yet both deployment URLs work. We deployed to both Kubernetes and ACI. The deployment URLs are roughly the same — except for the version — and you can visit both versions of that application. That's neat because you could go back in time and see the previous state of your deployments.

At the end of all this, once you are ready to clean up, we could run a waypoint deployment destroy, and destroy all our deployments. This deletes them and makes them so they are no longer visible. That is Waypoint.

What Else Is in the Initial Release?

I'm super excited to be able to have shown you that demo today of Waypoint, but there's so much more in the release that I wasn't able to show you. This slide talks about some of those things.

We saw build, deploy, release, exec, logs, etc., but there are so many more plugins I wasn't able to show you and other features listed here today. There's also a lot more that we want to build towards. This is an initial release, after all, so we're excited about where Waypoint is going to go.

So today, Waypoint 0.1 is now available. You can find Waypoint at waypointproject.io. Give it a try. We hope you love it. If you want to learn even more about Waypoint, we have a deep-dive session given by Evan Phoenix, who worked directly on Waypoint from the first day we started building it. He's going to be doing this directly after this talk.

Thank you very much and have fun with Waypoint.