Cloud Native Computing Foundation Online Programs, 23 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Demo: GitOps on Kubernetes with Consul, Vault & Terraform

Description

Peter McCarron (Sr. Product Marketing Manager, Consul) and Rosemary Wang (Developer Advocate, HashiCorp) demonstrate how to use HashiCorp Consul, Vault, and Terraform to implement GitOps workflows on Kubernetes. By combining infrastructure as code, service mesh, gateways, secrets management, and GitOps, they show how to manage, secure, connect, and deploy applications to Kubernetes using Flux and managed services, including Terraform Cloud and HashiCorp Cloud Platform (HCP).

00:24 - Agenda
01:01 - Introductions
02:08 - Set up Kubernetes, Vault, Consul, and database on AWS with Terraform Cloud
05:25 - Introduction to GitOps
06:41 - Infrastructure and application architecture
08:52 - Workflows for the platform engineer & developer
29:48 - Conclusion

Platform Engineer Workflow
10:23 - Configure service mesh certificate to use Vault
15:33 - Configure Consul API Gateway for services that need ingress
17:03 - Configure Consul terminating gateway for external services

Developer Workflow
17:48 - Secure service-to-service communication with Consul intentions
19:54 - Deploy applications with Flux
20:47 - Connect database to service mesh with terminating gateway
21:16 - Add an HTTP route to API Gateway
22:46 - Inject database username and password to application
24:36 - Configure Consul service mesh in applications
25:53 - Deploy a new version of frontend application
28:20 - Revert commit and roll forward previous version of application

To learn more, check out...
Demo Code: https://github.com/joatmon08/gitops-hashicups
Sign up for HashiCorp Cloud Platform: https://portal.cloud.hashicorp.com/sign-up
Sign up for Terraform Cloud: https://app.terraform.io/signup/account
Consul API Gateway: https://learn.hashicorp.com/tutorials/consul/kubernetes-api-gateway?in=consul/kubernetes
Consul Service Mesh on Kubernetes: https://learn.hashicorp.com/collections/consul/kubernetes
Vault on Kubernetes: https://learn.hashicorp.com/collections/vault/kubernetes
Manage Kubernetes with Terraform: https://learn.hashicorp.com/collections/terraform/kubernetes
Vault as Certificate Manager on Kubernetes: https://learn.hashicorp.com/tutorials/vault/kubernetes-cert-manager

#Consul #HashiCorp #Vault #Terraform #GitOps #Kubernetes #Flux #ServiceMesh #SecretsManagement #Security #TLS #InfrastructureAsCode #CertificateManagement #APIGateway #NetworkPolicy #Envoy #AWS

-

If you liked this video and want to see more from HashiCorp, subscribe to our channel: https://www.youtube.com/c/HashiCorp?sub_confirmation=1

To learn more, visit our hands-on interactive lab environment, HashiCorp Learn: https://learn.hashicorp.com/

HashiCorp provides infrastructure automation software for multi-cloud environments, enabling enterprises to unlock a common cloud operating model to provision, secure, connect, and run any application on any infrastructure. HashiCorp open source tools Vagrant, Packer, Terraform, Vault, Consul, Nomad, Boundary, and Waypoint allow organizations to deliver applications faster by helping enterprises transition from manual processes and ITIL practices to self-service automation and DevOps practices.

For more information, visit: www.hashicorp.com or follow us on social media:
Twitter: @hashicorp
LinkedIn: https://www.linkedin.com/company/hashicorp
Facebook: https://www.facebook.com/HashiCorp

A

Hey everyone: uh this is peter mccarron here and I'm joined by rosemary wong hi and we're going to talk about git ops, workflows with the hashicorp stack. So what we're going to do is we're going to use terraform to deploy, vault and console to achieve a git, ops, workflow using flux and a nice coffee application that we use here internally at hashcore, but before we do that, uh let's dive a little bit into our agenda and do a couple of short intros.

A

uh So one of the things we're gonna do is we're gonna walk you through the build of our environment. uh We've gone ahead and kicked off. Some runs already and we'll walk you through the code and everything that's going to be there we're going to talk a little bit about what our end stack is going to look like so we'll show you the initial environment, but then we'll talk a little bit about what we're actually going to do. Moving forward, we'll break our demo into two different parts.

A

So we're going to talk about once I've prepared the environment. What do I, as a platform operator, need to do to get it ready for my end user and then on the second part of that we're going to deploy our application as well as make some iterative changes and establish our git ops workflow from there. We'll give you a couple of resources about how to get started and then yeah.

A

B

A

Quick introduction, my name is peter mccarron, I'm the senior product marketing manager here at hashicorp by console- and I will be your pretend platform operator for today.

B

And I'm rosemary wong, I'm a developer advocate here at hashicorp. I am somewhat a developer and mostly an operator, but today I'm going to be playing the role of a developer, who might need to make some configuration to the platform and infrastructure, and I am empowered to do so. Thanks to peter's established infrastructure patterns.

A

The advantage here is that rosemary has the developer operator knowledge necessary to make this all work, whereas I just got to do the terraform run. So this is great all right. So I think one of the things we wanted to do before we really got into slideware is that we wanted to walk through our environment, so walk through the terraform code. Kind of show you what we built uh we're using all of hashicorp's cloud products for this.

A

uh One of the main reasons is because rosemary and I are located in different parts of the us rosemary's on the east coast and I'm here in colorado, so this makes it a lot easier for us to share and have kind of a collaborative collaborative tool set in the cloud. So let's switch over and show you what that looks like all right so we're here in our terrapro cloud environment, and you see that there's three main workspaces that we're going to be using today. So we have our infrastructure workspace.

A

We have our database workspace and we have our vault workspace. Each of these are being run off a different repository that we're collaborating on, and the reason, as I mentioned, that we're using our cloud products is because we're located in different areas. It becomes a lot easier for us to share information and share code by using terraform cloud if you go ahead and click into the infrastructure workspace.

A

This essentially is going to be the environment that we're building that I've given to rosemary to be able to deploy our coffee application on. What we're building in here is we're creating an eks cluster on aws. We are creating an http console cluster, we're deploying a client to that eks cluster using helm and we're using http vault.

A

So we've built all these different resources and configured all the necessary permissions and iam policies, as well as the crds that we're going to use for the api gateway, which will be a part of our application, demo and rosemary. If you want, you can now walk us through a little bit of the database as well as the vault workspaces too.

B

Sure so our coffee application needs a database. I created a postgresql database in amazon, so it's managed. It is not within the kubernetes cluster and the database itself starts out containing nothing so as a developer, I'll load in the database that I need. I also create some initial configurations in console.

B

So that way my application can connect to this database uh since we're going to be using console service mesh today, I need a way to connect from my mesh to my database and do it securely, so I have deployed some initial staging so that way I can register my database as an external service to console as well and I'll explain a little bit more about how we connect that mesh to the external service, but I just wanted to make sure I stage all of that as a developer and operator. First.

B

The other thing we configured was vault. Vault is going to store our secrets, not only the database, username and password, but fun fact. I have to have access to the kubernetes cluster as a developer, and so this vault setup includes a back end for my applications in kubernetes to authenticate uh to vault correctly and retrieve the database credentials, and I also have a secret engine that issues aws credentials. These aws credentials issues to me the developer, with limited access to kubernetes.

B

So that way I can get my config and deploy the applications and do some initial testing.

B

But overall, this is a great way to set up ephemeral credentials to both applications uh and users who may need temporary access and, as we continue way forward, you'll see that a lot of the access from the application to the to vault for the database credentials is going to be done through annotations, all right, peter. What's next.

A

Awesome and so, as we thought we built all this already, it's a lot of stuff takes a little while for it to build, so we wanted to make sure it was up and running by the time we were recording this video.

A

So what we can do now is: let's go ahead and switch back to our slides for a second, so we can discuss a little bit about what our overall stack and what we're going to actually be achieving as part of our demos, all right so back to slides just for a little bit um quick refresher on git ops, if you're watching this you're- probably familiar with it. But if you just heard the term and you're kind of saying well, I want to know what this is all about.

A

In a nutshell, what we're trying to do is that we're trying to apply devops best practices to the infrastructure life cycle, so things that application developers are already doing things. Like version control, collaborative tools, you saw we're using terraform cloud, so we can combine a number of our repositories adding in different compliance pieces, so obviously creating like limited credentials for vault and then having ci cd processes right so where I'm making those iterative changes, and I can continuously deliver them and make those changes using different tooling.

A

uh So, as I commit changes to the code, not only do my applications change, but anything on the infrastructure side as well, and this is really important because one of the things that we know- and we believe at hush corp- is we're trying to align the application developer life cycle and the infrastructure developer life cycle. You know these teams are dependent on one another.

A

They're gonna often share a lot of the same skill sets and they're really trying to achieve the same goals, and if we can create better collaboration and aligning those work streams, then it's going to make everybody happier. You know network. Doesn't become a bottleneck you're not waiting on the security team to approve something you're, not waiting on the developer team to initiate some different changes, we're just keeping everything flowing all together and really achieving that true ci cd workflow.

A

So what exactly are we going to build in this? So this is a very much an architecture diagram, but I am a marketing person. So that's what I do. uh We are going to be committing a whole bunch of changes into our github repositories. You saw them already go in we're applying those changes through terraform. So on my end, what I did is that I ran the tariff on apply to construct that http console cluster, that you saw as well as vault.

A

What I'm going to do afterwards is I'm going to go into it to do some manual changes because there's going to be some additional permissions and additional things we want to have in place for when rosemary, deploys her application uh rosemary, walk us a little bit through what you're going to be doing here as part of the stack.

B

Yeah, so the second part of this is deploying the application we've led up to this point, where we've constructed infrastructure to support it right, including perhaps an api gateway, so that we can route to a front end. We needed a database, we needed vault. We need a console. We needed all these things so now.

B

What I'll do in the second part is talk about how we deploy the applications using flux to support that git, ops, workflow, we're looking for so when I commit changes to my application and their kubernetes manifests in version control flex will automatically pick them up and deploy them for me. So what you'll see is that I'll make some changes in my kubernetes manifest and then flux will pick it up and deploy them to the kubernetes cluster, and what we should get at the end is a coffee application that shows us a list of coffees.

B

We can purchase.

A

Great and then just really quickly to remind folks about what we're doing from an application side. So we showed you the infrastructure piece. The application itself is going to consist of a few different components. uh We're not going to be doing the echo server during this one, so focus on the right side of the diagram. Here, we're going to be deploying our front end as well as a couple of different apis, we're going to have a payment and as well as that, database that rosemary mentioned earlier. We're also going to deploy the api gateway.

B

As a front end for that front,.

A

End service, so that we can route all the traffic through the api gateway, as opposed to hitting the front end directly.

A

This is a nice functionality, especially if I was going to do some different versioning like rosemary's, going to do later, or if I had a number of different apis that I wanted to be able to balance requests through. I could use the api gateway to front those requests from external clients.

A

Okay, so these are the workflows that we're gonna do. As we said, we've already deployed http, vault and console using terraform cloud so check. We already got step one done in our workflow. uh The next thing we're gonna do is we're gonna update the console, connect ca to use ball. You know, one of the things that we always recommend is that if you're going to use console service, mesh or you're going to have any type of root certificate management, you want to use something like both to store that root certificate and then create intermediate certificates.

A

Based on that, we just know that we're housing it more securely. So if I'm using this for a production application, I'm not exposing my root, ca or saving that root ca as say like a kubernetes secret. At that point, I'm going to deploy the api gateway, which rosemary will be able to use for the routes so rosemary and then, as you said, what what are you going to do as part of your workflow.

B

Yeah, so we have flux running in the cluster, so that way it can pick up changes from version control and deploy the resources in kubernetes automatically for us. So what we're going to do is deploy our application and I'll show how the application is retrieving information from our database using dynamic credentials. So it's getting a new username and password for every new pod that it creates.

B

The other thing we're going to show is how we're routing traffic between the services, so how we're controlling them using some kind of network policy and we're going to commit a change, we're going to increase the version of our front end and apply it via flex, so we're going to use the api gateway and the route from the api gateway to the end application to show whether or not a new version works.

A

All right, so, let's demo it.

A

Okay, so we switched over to our demo here. So, as you can see, we have our console cluster. That's running you'll notice, nothing up our sleeves. We have no application running outside of the database that we showed you initially as well as determining gateway that we deployed as part of console. So this is just like kind of our initial state. We also have our vault instance.

A

That's running you'll notice that we have our aws secrets engines, that's already been established, as well as the database for hashicops, so we've created those secret engines, but we haven't created any of our other permissions yet so the next thing that we want to do is we want to change this over to where we're using vault as our connect ca so because we're using console service mesh, it's going to issue mtls certificates to all these different services that we deploy later.

A

The nice thing is that if we store our root certificate in fault, we know that that's protected, but we still have the benefit of being able to have console, distribute those intermediate certs. So, let's flip over to the terminal and we'll give this a try.

A

So here in a terminal, the first thing that I'm going to need to do is I'm going to need to create a ca policy for console to be able to leverage. Then I'm going to have to create a token based on that policy, which I'm going to then pass into console to have it update the connectca that it's using so because we're using hcp.

A

The first thing I have to do is I have to make contact with it, and so I just got to set a couple of environment variables so that I can interact with both. So let's make sure that vault is working.

A

All right, as you can see, I have a bulk cluster. That's initialized! uh We do not have it sealed. Currently, this is the one that we created as part of part of our terraform deployment.

A

So the next thing that I need to do is I need to use the root token that I created from vault or an intermediate admin token from vault to be able to make the changes and create the policy that I need to do so I'm going to go ahead and do that here.

A

The next thing is: let's take a look at the policy that I'm going to be creating.

A

So, as you can see, we have a series of different paths that we're setting up. This is basically just saying that console is going to have the permissions to be able to create intermediate tokens or be able to connect to the root token or the root certificate that we're going to have that's going to be stored involved. So I need to set these up in order for the console ca to work uh correctly, I'm using the console managed policies if you're interested in some of the vault managed policies. uh We do have a learn guide.

A

That shows you the difference between the two so I'll go ahead and create my policy name.

A

All right, we've created our connect, ca policy and we need to go ahead and create a token all right, excellent. We have our token. So now we are done on the vault side. The next thing that we're going to need to do is we need to actually hit the console api to make the necessary changes for how for updating this policy and then switching over to connectca.

A

So the way that we're going to do this, I'm going to actually exec into the pod that the console client is in if you're, using a public endpoint for console. You could do that just via your terminal, but you know in a production environment you're, probably not going to have public endpoints available, so you'd want to use the private one instead, so switching terminal screens here so again, just kind of showing that there's nothing on my sleeve I've exact into this pod. Already I already got a config.

A

You can see that the provider that we're using is console, and it has the different configurations that we're going to be running so now. What I'm going to do is a couple different things. So I've already added a bootstrap token that I copied previously uh into here and set it as an environment variable for my http token uh you're. Seeing a lot of information here, but really all I'm doing is just passing in manually the json that I could do as like a payload file if I was not doing this in the pod itself.

A

So I know this looks like kind of like a long command, but really it's just all the different information that we need to set up. The connectca.

A

All right, so nothing happened. That's what we want to see usually like in linux, whenever nothing kind of errors out we're, usually good. So now, if I go ahead and I pull up my connect ca again, you'll notice that we switched over where we're now using vault. So what this means is that retrieving that root certificate from the vault cluster that we've given here in the address, we have some predefined time to lives on the intermediates that we're going to be able to do and we can create the different leaf certificates.

A

So now, when rosemary deploys our application, I know all the mtl starts that are going to be generated are based off. This fall one. So.

B

A

Is just a nice interaction between the bulk cluster and the console cluster that I created and it's something that we typically recommend for users to do when they're going to be deploying production applications. So now that we did that we can exit out of here and the last piece that I'm going to want to do? Is I'm going to want to set up the api gateway? So, let's take a look make sure I have that file.

A

All right, so one other thing I want to show here is that if I do a get pods.

A

It'll show up eventually you'll.

B

Notice that I have this.

A

Api gateway controller, so, as part of the terraform deployment that I did, there was a series of customizations that we put in there for crds. uh What this was doing is it was loading the necessary crds for us to deploy the api gateway controller. The api gateway controller is kind of like the brains, everything this is where it's taking all the gateway configs and it's going to apply those to the gateway service that I'm going to deploy here.

A

If I show you that here we're naming this api gateway, we have the class name that we defined as part of the installation process. What we're telling it is that we want to listen for external client traffic and listen on a secure connection and the way we're doing that is from a tls certificate that I created when I deployed console so we'll go ahead and apply this service, and I gotta tell it that it's a file.

A

So this is how you know that I do actually type some of my commands, not just copy paste all right and we created our service. So let's go flip back over to our ui here and as you'll see, this is coming up a lot online. We already have this registered. It's the console api gateway, it basically acts as an ingress gateway, and now what rosemary would be able to do is apply different routes to it for our various services.

A

So with that I'll hand it over to rosemary who's, going to walk us through our application deployment and some of our other changes.

B

Yeah, so what's important to know, if you stay on this console, console ui, there's two gateways, there's an ingress gateway and a terminating gateway. Remember we talked about our application is a is in a mesh and we need a way for that mesh to connect outside, but also for something outside to connect in. So we have a front end as part of the mesh that we need to connect to the api gateway. So I'll show that and the second thing I'll just briefly briefly talk about is the terminating gateway.

B

So it allows us to link from an internal uh internal service in the mesh to our database, which is not in the mesh. It's a managed database and the terminating gateway allows us to treat it as such. So one of the things that I'm going to do is show you a little bit of the configuration we have today, so we're doing everything in the spirit of get offs right. So we have flux deployed to the cluster already, and I've already deployed some uh some of the setup for customization.

B

uh Today we have a an application in the form of this customization and the customization includes some of the manifest that we're going to talk about and and deploy. The first thing that's already deployed are service intentions. Console has this idea of network policy in the form of service intentions? These uh add effectively envoy filters uh in various um various ways to the service mesh, so you can control the traffic between services so allow or deny, and you can even do- allow or deny based on paths. So here I have a public api.

B

The front end is going to connect to it and we don't want the front end to connect to the public api over the health endpoint. It doesn't really need to and there's some fine grain control that we have over authorization as well as any other traffic that needs to go to our public api.

B

Furthermore, we have some information here about how we allow services to connect to the database you'll notice that only the product api is allowed to connect to the database and not every single service. This is great because we don't want every single service accessing the database information unless we can, unless we absolutely need it. I also have my payment service, so I have product uh being allowed to connect to my payment service as well as public api connecting my payments.

B

So if you imagine, if you have some kind of compliance requirement around a specific service and you can control whether or not specific services in your mesh can connect to something related to payments right, so that could be like credit card information which is in this case or other personal, identifying information.

B

We also have another intention here which connects from the uh connects from public api to product, so in that sequence, that uh peter showed before we're basically implementing the intent of our network policy and expressing them in this kubernetes ammo.

B

So what we're going to do is in true get ops fashion, I'm going to now deploy everything that we need um we're going to do this by uncommenting, because that's actually, if you look at my cluster right now, I'll show you there is no deployment, we're deploying to the default name space just for visibility.

B

um But if you actually examine it right now, there's nothing deployed. So what I'm going to do is uh double check that I can make this change and what I'll say is a descriptive, commit message of deploy, hashicops application and we're going to push that commit. So once we push that commit we're going to give it a little bit of time for flux and our get ups framework to reconcile that reconcile that commit. In the meantime, I will show you a little bit of this postgres demo. So remember.

B

I talked about the terminating gateway before and here peter deployed the terminating gateway. I need to link it up right, so I need to tell my postgres service: hey you. Should you should belong to the terminating gateway, so I created an external service called postgres, and this is where, as an application developer, I would link this up to a terminating gateway. So it allows this external service to sort of join the mesh a bit. It's a nice way to just declare it as a kubernetes manifest.

B

So I can just add it as part of my application deployment. The other thing is that I need to control inbound access to my front-end application. After all, my users need to order coffee. So what I've done is I've created an http route. Peter has kindly created the api gateway, so I do not have to look at any of his certificates.

B

I don't have to know too much about you know what what certificates are. You are used to support the application. All I really need to know is: where is uh where is a user going to route to first, so I create an http route object and what that will do is pass any path at the root path to my front and service on port 80.. Again, don't really need to know too much. I don't need to handle anything about certs uh peter, even handled all the certs between the services in the mesh too.

B

So I don't have any certs in my applications either. um Instead, they have mtls between services within uh the within the mesh and it's handled by vault. So all of this is pretty convenient. So if I check my deployment, let's just see if my if flux has picked up the changes and has started to deploy my application, you'll notice, that there are some applications and there's the front end payments, product and public.

B

The database remember is outside of the mesh, so you won't see a database pod running, but product will still be able to access it and the reason why product can still access it is that it's going through that terminating gateway and, more importantly, my credentials to access the uh postgres database is also secure as well. So I'll show you a little bit of that when you try to connect a service to to vault, to retrieve secrets like database secrets, you'll need to use a set of credentials. Sorry annotations on the kubernetes deployment.

B

So as a developer, I just add the annotations. Some of these can be set by default by let's say peter my platform operator. You can decide which things are appropriate but as a developer, I set connect inject true, I'm using the vault agent sidecar injector this time. So I'm not using the secrets secret store, csi provider for those who are familiar with it, but what this will do is create a sidecar since it's creating a sidecar, keep in mind that you also have a service mesh sidecar.

B

So since console is a service mesh, it's running a service mesh. uh You have an order of operations here in terms of sidecar initialization, so as a developer or anybody who's working with a service mesh plus a secrets. Management sidecar like this, just make sure that you initialize the secrets management sidecar first, so it can retrieve the database credentials successfully before you initialize the service mesh. So that's something to note.

B

On top of that I'll also template out a file. This contains my database connection string. I connect through localhost because I'm using my console service mesh in upstream and I'm declaring an upstream to my postgres database here. My postgres database again is external, so it behaves as if it is part of the mesh and that's what's fantastic about this kind of configuration.

B

So I'm connecting over localhost and I'm passing in the username and password dynamically generated from vault. So anytime vault needs to create new credentials. My application can be restarted to pick it up. That's the important thing, the other configuration that you should consider as you are configuring a service in your service mesh I'll, show you one that's a little bit further downstream I'll. Show you the public api, for example, the public api you'll notice does not have the additional annotation I'll show you kind of to the side.

B

uh It doesn't quite have the same annotation specifically, it doesn't have this service upstream annotation, and that's because this is using transparent, proxy and so rather than going through localhost and then passing it through the proxy to the the next service to the upstream service. What I'm doing is I'm allowing kubernetes dns to resolve uh the resolve, the proxying for me, so I don't have to do anything but declare just like kubernetes dns, the name of the service, so overall pretty easy, not too many changes from uh from a developer point of view.

B

Now, if you can imagine, we always have to update something right in our in our in our kubernetes services. So this time I'm going to take front end and I'm going to update it to 1.10.1 we've graduated we've gone from, I think: zero. Seven, zero, yeah, zero, zero, seven to zero zero one and what I'm gonna do is I'm gonna add in a new configuration.

B

So if I do get status and I check my changes- I'll add it and once again I will do a descriptive, commit message, update, front end service to version 1.1 and I'll push that, and what this will do is automatically get picked up by flux. It takes a little bit. I think I set the synchronization to a minute or two, so it may take a little bit of time. But what you'll see after a couple minutes is that it will get deployed. A new version of the front end will get deployed.

A

While we're waiting for that to get deployed, one of the things that I think is really key here is because we did this on an http console. You know we have a default, deny policy in place for all of our intentions, so the intention file that rosemary showed earlier. That needs to be done in order to secure the specific routes and the specific type of services that we want to talk to another nice thing there is that we could also have had a different repo or we could collectively control what those intentions look like.

A

So if we were maybe trying to say like all right, we don't want the developer necessary, defining what services can talk to each other. They could instead submit a request to us. We could merge it into a separate repository and it would apply to the console service mesh. So there's a lot of cool things that you can do to really control how the mesh is able to route things um and as you're, making these changes and iterative iterating on them. That's something! That's really nice! Also, the.

B

A

A lot more that you can do beyond just like putting on the front end, we can attach it to different host names, and if we wanted to have a public domain that we could hit for users, they'd be able to actually do that as well. So if we had something registered with the various like dns service, we could actually use that to front end our application and then, when rosemary made, this awesome change to our really cool new version.

A

1.0 1.0.1 uh our domain would stay the same, but the route would still hit to the new service instead. So the api gateway does a lot of really cool stuff. For us. We're really setting up a very kind of uniform service that, as we make these changes, uh we can just iterate on them without having to change all the back end pieces.

B

Okay, so let's check, if our new front end has deployed our new front, end has indeed deployed um and we're going to use the api gateway to check whether or not it is working so I'll, go and use the load balancer in front of the api gateway and you'll notice that when I try to access it, my front end is unfortunately unable to query all coffee. So we know that something is wrong with the new version of our front end, which is a little bit unfortunate for us.

B

So what we're going to do uh is in again in true uh get out fashion. We are going to revert our commit that changed the front end. So what I'm going to do is revert the commit make sure we go back to the original I'm going to push the changes out and then we'll wait for the new front end to get deployed again, so we're going to I'll show at least the new front end.

B

As you can see, it's been running for a few seconds now and the api gateway does not change it automatically detects it. It automatically is connected to the front-end service in kubernetes, so we don't have to do anything and what we'll do next is give it a little bit of a chance to refresh.

B

So we have uh the working application again and I will make sure to share that you'll notice that if we refresh this the uh apd front end for the api gateway, I once again have my coffee application up and running again, so I don't defect my user. I have determined that my new version of my front end is not working and I can go back and revert the changes accordingly and that completes the developer workflow for my coffee application and all of the infrastructure we've set up today.

B

A

So we went through our developer workflow, but the real important thing is that we showed we had all this plumbing connected right. So we set up a shared service that rosemary and I could both use to where we are as we're iterating on changes. The developer can focus on improving the application and bursting out our front end versus worrying about what happens when they deploy it and making sure that everything is connected and secure.

A

So what are the next steps here? Well, first and foremost, if you want to try it out, go sign up for the hashtag cloud platform or terraform cloud. You could try the tools that we did as part of this I'd also recommend checking out our learner tutorials.

A

We have ones that we did for the api gateway, which follows very similar workflow to what we did here. We have ones for bald secret injection. So if you're only curious about the dynamic credentialing, we also have some progressive delivery ones if you're using either kubernetes or if you want to try out some nomad ones, also.

B

Make sure you check.

A

Out our resource library, there's a handful of things that we have available where there are a number of videos that are similar to this one maybe show some different use cases and, of course,.

B

Talk to us on discuss.

A

If you're trying this out- and you have some questions about how to get it set up, we have a number of moderators and folks who are willing to answer your questions. I know I've seen rosemary in there a couple times. I make the occasional announcement, but uh we're always happy to help out and answer any questions, so just want to say thanks for watching this video. uh Hopefully this helps you get started with establishing your own, get ops, workflow and good luck. Thanks.