DEV Community

loading...

Golang : Work with config files

Aditya
・1 min read

Configuration files play an important role in the application development lifecycle. We build and deploy applications onto multiple environments and each of them must require a certain set of configurations to run.

Running applications on multiple environments require configuration to be set properly.

Golang builds a single binary of the whole application which can be run on the specific environment be it a linux binary or a windows binary.

With the release of Golang v1.16 Embed feature was also released and with that we can mount the config files onto a structure in our program while building the binary itself and we do not need to ship the configuration files explicitly.

Read configuration files

The below snippet can help you read the configuration file using the embed package.

Application Structure
image

config.yaml

name: Test_User
age: 73
Enter fullscreen mode Exit fullscreen mode

main.go

pacakge main

import (
    ...
    <imports>
)

//go:embed config.yaml
var config embed.FS

type Conf struct {
    Name string `yaml:"name"`
    Age  int    `yaml:"name"`
}

func main() {
    var configs Conf
    configs.readConfig()
    fmt.Println(configs)
}

func (conf *Conf) readConfig() *Conf {
    yamlFile, err := config.ReadFile("config.yaml")
    if err != nil {
        log.Fatalln(err)
    }
    err = yaml.Unmarshal(yamlFile, &conf)
    if err != nil {
        log.Fatalln(err)
    }
    return conf
}
Enter fullscreen mode Exit fullscreen mode

Build the binary and we don't need to worry about shipping the config.yaml while deploying our applications on any platform.

Discussion (2)

Collapse
robinhuiser profile image
Robin Huiser

Hi Aditya,

Thanks for sharing your experience with Go and configuration files!!

Reading your article, I hope you do not mind I provide some next steps for improvement considering configuration management in Go?

While your solution works (no doubts), it does impact your code base in either:

  • having separate code bases / branches (one for each environment)
  • embedding environment configuration in your code repository

Going down this path you are forced to generate environment specific binaries which is not in line with best practices (see: 12factor.net/codebase) -- 12 factor apps is a good read, something I hand-over to each developer in my teams!

As a possible next step, I would suggest to have a look at Viper in combination with the Golang port of Spring Cloud Config Server to externalise, centralise, version-control & secure configuration files with Vecosy (github.com/vecosy/vecosy) and for runtime feature flags: github.com/thomaspoignant/go-featu....

Again, thanks for your article and I hope you take my feedback "the right way" - we are here to share and learn from each other!

Best -- Robin

Collapse
adi73 profile image
Aditya Author • Edited

Thanks for the feedback Robin!