Software Architecture in Golang: Externalized Configuration Pattern

hello my name is mario welcome to another software architecturing video in today's episode i'm sharing with you the externalized configuration pattern when we are building applications one of those things that we need to define is configuration one of the most common examples will be defining database configuration we have a username password and hostname that depends and really changes depending on the environment maybe we have one for production maybe we have one for development and one for qa in the context of this video i will show you different ways to define configuration options that we can use as an input for our application and more importantly how we can use the externalized configuration pattern with an example and go so let me show you the code as usual the link to the code is in the description of this video so please feel free to check that out i will show you three different ways to define configuration options they may be you know harder or more easier to implement but i will show you the way to do it using an externalized configuration in the end so first of all we'll be using a parameters or flags and in this case we have a main.go file that uses the flag package to pass in some values and then we can parse and use them as the option that we're we're trying to use in this case we'll be password this is a super really example super simple example i want you to think in the context hey our application is going to receive is going to be receiving some values using flags or parameters now how does this work in real life if we go and build this application you will notice that we have a file called parameter that by default if you notice is using the value that we defined right here now what is the most interesting thing about this example is that if we go ahead and define a password and we say abc one two three four now all of these values that we define right here you will see that there are plain text so if for whatever reason and there is some login that happens to be applicable to the machine that this application is running now this information information will be available for somebody to see this is a security concern this is one way to do it let me show you another way the second example consists of using a properties file or a configuration file things that i think are really common nowadays that where you're defining is basically a way to embed the configuration into your binary or next to your binary in the context of go i'm actually using the go embed configuration the property so we can actually embed it in the binary itself now the way it works as you may imagine is that it's going to be reading that configuration from those files to pull the values from those embedded files so this is something that is typically used in languages and frameworks that happen to be used in java or maybe a ruby with ruby on rails or python but in go is again it's another way to do it if we look at the code you will notice that i'm opening the configuration from the embedded file and then pulling the values from the meta file so the way it works if we go and build that binary you will see that now i can pass in by default it will fall back to the dev configuration that we defined before the dev environment that we used before in the previous example but if we want to specify some value we will need to pass in an argument that defines the environment itself so if we go back to example and do m prod you will see that is putting the value from in this case will be prod for production and in the other case will be dev for for dev if we go back and see the examples you will see that those are the values that were saved in the configuration before so prod is using plot one two three dev is using dev one two three the last example i have consists of using the recommended way for building 12 factor applications i'm going to leave the link to that specific way of building applications in the description below which honestly this is the way i recommend using configuration values for production applications that happen to be using cloud native environments so the way it works is really simple let me show you so we have this environment variable that is coming from your local fork program that applies to your environment in this case it's called password and what it's going to be doing is literally pulling the value from the environment variable and print that out is really that simple so if we go and run this you will see that let me build it first you will see that hey three vars there is no password but if i do something like password one two three four you'll see that the value is being printed out right here so these are three ways to common ways to define inputs as configuration options into our applications we saw parameters or flags we saw files or embedded properties and three we saw configuration options using environment variables let me show you how you can do something similar using an externalized configuration service next example consists of using a service called vault from hashicorp there are other ways to do this for example aws ssm and azure also has their own storage uh way to define the secrets so just one i want to tell you something this is not about using hashicorp or aws ssm or azures did they want from azure provided a way to define a way a data store a secure data store that is that is contains all the configuration in a way that is secure for your applications so you don't have to literally using plain text when you are configuring those when you are trying to run them okay i want to show you the code used for context but literally this doesn't matter too much so this is an example that i used previously in honor of videos i will be leaving the link in the description as well so you can review that but basically consists of connecting to the data store passing in some arguments indicating the key that we need which is encrypted by that service and then using it in our own application so there's nothing really extraordinary we connect to the client we get the value and we do something with it so if we build this one you will notice that the value is coming from hashicorp the instructions are in the description of the readme so you can review that as well what is missing right here is that i'm missing a value that is coming from this a configuration that allows us to connect to the hashicorp vault server in this case it will be this value right here that i have is an environment variable called fault token that typically is injected when you're running your application with your container containers containerization service so if you're using ecs typically or kubernetes or whatever the containerization service that you're using it will be injecting that configuration together with the configuration that you're using for on your server so it's not like we're going to be passing in a plain blank vault token value i want to make that clear in this example because we are running it locally we need to pass in that volt token value so if you saw before you saw you notice that is connecting is not connecting because if we have a permission error so what we have to do is do a volt token my route which is a way is the value that i use when i instantiated the docker container so if you run this again you will see that now is actually getting the value that we are expecting let me show you the last example and i think this is the most important one that combines all the four things that we saw before this final example includes the previous four in a way that i think it makes the most sense in the case when you're trying to use the externalized configuration pattern i'm going to be leaving also a link to a blog post that i wrote a few years ago that defines a clean way to indicate environment variables that happen to be used in parameters in the example is using aws ssm but it applies to any secure data store so you should be the same now the important bit is that we are going to be defining when we are building an application we are going to be defining a configuration layer and the way i'm representing that layer is by building a type in this case called config and this config in this example is part of the main package but typically this will be a package that is outside of main that can be reused by different binaries that are part of your application let me show you the actual implementation of that config file if you remember the way we show we implemented previously in the in the in the in the example that i show you is literally just receiving a token receiving an address and the token is coming from the vault token environment variable and the address is the http url that you're going to be using for connecting to volt so this basically is kind of um extracting out everything that we need for pulling values that we need from our secure data store is a really simple example i think it's important because we have a new config right here and if you see we have a function that is called get that returns the information that we need which in this case will be the string and the error and it does everything that we are supposed to be doing with the details that we need for this application to run as usual all of this is in the links uh below so please review the code everything i think the important bit about this is that you have a secure data store that you can use for storing all your information in a way that is tokenized and not you're not leaking values that could be potentially been at risk for your company for your application and whatnot so let's jump into the conclusions i will talk to you in a few so that's it this is the externalized configuration pattern with a few examples in go remember the whole point of this is to define a secure data store that all your applications can access that secure the restore is obviously secure but in a way it's storing all the credentials all the tokenized values that you need and it's you are not leaking that information when you're when you're running your application either via parameters or environment variables or whatever the case may be hopefully this is useful for you i will talk to you next time until then take care and stay safe see ya

Channel: Mario Carrion

Views: 2,672

Keywords: golang, go lang, golang tutorial, go lang tutorial, golang beginners, golang for beginners, learn golang, golang software architecture, claim check pattern, software architecture patterns, microservices messaging, externalized configuration, golang vault, golang hashicorp, golang externalized configuration, golang hashicorp vault, hashicorp vault

Id: o9dDrVMylQg

Length: 11min 34sec (694 seconds)

Published: Fri Aug 26 2022