Configuring the Service Module

[00:00:00]
>> Erik Reinert: The last thing we need, and this one's probably the most intricate of all of the configuration objects. And you'll see as we go more and more we get a little bit more advanced. Here is the service module. This is the service module right here and it does quite a bit.

[00:00:18]
Now, effectively the first thing we do is we tell it which capacity provider that it's in. Again, if you notice at the top of the editor you'll see spot right there, well, that's why those match in naming convention. That I'm telling the service, hey, I want you to provision to the spot capacity provider.

[00:00:37]
If it doesn't have a capacity provider that it matches, it will not deploy. So it'll just be in a broken state. Cluster ID, we give it the cluster ARN. Cluster name, we give it the cluster name. Image repository. So this one's a little bit of string interpolation that we've got going on here.

[00:00:54]
But it's just your ECR domain, it's just the ECR domain where we push all of the images to. I'm just calculating the ID as well as the region that you're pulling from effectively or that you're building services on effectively. So you'll see I have an image repository as well.

[00:01:10]
FEM fdservice image tag var name module cluster listener arn, which is for the listener arn. And again, the image tag, for example, is a variable. So that means that we can give it from a higher level and if we need, where else name service because we don't really have any other service.

[00:01:33]
So we can literally just call this one service path. So again, I said that we had the ability to map which route the load balancer can respond with. So in this case we're mapping just slash star. So we're mapping everything. The port that the service listens on and then the VPC id.

[00:01:51]
And that's really everything related to the actual like resources or configuration of the service itself. The next lines are all custom. The next lines are all custom and written with the intention to enable the developer to do what they need to do. So the first one is the config, and the config is basically the unencrypted open plain text environment variables.

[00:02:15]
So you've seen us do the Google redirect URL and the goose driver, right? Well, this is where we add environment variables for the service. And to be fair, I don't think you really need to manage environment variables in parameter store, I think that's a little bit extra work.

[00:02:33]
You can if you want, it's up to you. But in this case I don't think these would change as much as secrets. So this I feel is fine to have in terraform, but again, it's entirely up to you. Secrets are more specific because you would not be storing them in terraform anyways.

[00:02:50]
So you have to figure out a way to provision and manage the secret without caring about the value. That's why we do it the way that we do it. But with a config I think it's actually totally fine. Again, you can do nice stuff like this where I might not know what the distribution domain is, but the automation does.

[00:03:08]
So I can inject that into the environment variable directly and I don't have to worry about it. That's how we solve that problem. I know somebody yesterday asked how else could you get the Google redirect URL? Well, that's how we do it. We just basically get the domain name from the distribution resource.

[00:03:26]
Then yeah, we get our secrets as well. So Google Client id, Google Client Secret, Goose DB and postgres URL, those are all added and these will get created as entries inside of ssm, inside of the parameter store.