Include config file as part of app binary

[jurukode]

Description

In order to provide deployment consistency, we need to include configuration files as part of the application binary, especially during app deployment to avoid unintented changes made from the config file if copied manually.

To Reproduce

Currently we need to copy paste the app binary and config files separately.

Expected Behavior

When building the app, the configuration files will be included as part of the binary. Hence, the user just need to copy the binary to deployment env.

Environment:

Additional Context

[kaplanelad]

Consideration of the issue led me to the following proposal:

• Create a new configuration file named imbede.yaml, for example.
  The YAML should be like this:

development:
   ....
production:
  ....
custom-env:
  ....

• During the build process, load this file if it exists at a cost.
• At the runtime, if Loco builds with imbede.yaml points the configuration only to this file content

@jondot any other thoughts?

[tjyang]

For my understanding, This request is more like this one at rust-cli/config-rs#408
End goal is to have myapp2-cli has at least config/production.yaml and and some files under frontend/* embeded inside the binary.

[me@rocky9t01a myapp2]$ tree -L 2
.
<snipped>
├── config
│   ├── development.yaml
│   ├── production.yaml
│   └── test.yaml
├── db.sqlite
├── examples
│   └── playground.rs
├── frontend
│   ├── dist
│   ├── favicon.ico
│   ├── index.html
│   ├── package.json
│   ├── pnpm-lock.yaml
│   ├── README.md
│   ├── src
│   └── vite.config.js
<snipped>

20 directories, 20 files
[me@rocky9t01a myapp2]$

[jondot]

@jurukode i'm not sure about config files being embedded yet, because they are config files -- they are supposed to be changed/tweaked/etc.

I believe your pain point is a single "deliverable", which you can get with a docker container.

Just to reiterate -- I think embedding is cool, but i'm not sure its what most people would expect.

[jurukode]

Deliverable is not the main concern here, it's more about deployment safety and reproducibility to prevent human error due to copying wrong config files.

I understand your intention here is to provide easy tweaks without need to recompile the app. But, I prefer to have single binary that can be easily versioned without additional dependencies.

P.S.: you can always tweak the config via env variables anyway 😁

[lpj145]

By the way @jurukode you can achieve this just using some cool const fn and in that case you have to load the files that you want to embed at the binary, is so easy I guess, I don't it will be good to have this thing on loco maybe they can support it but, I don't think it will very usable, the most way that companies uses to is just to provide some vault-url protocol to load entire env's directly from some vault product like hashicorp.

[jondot]

@jurukode got it. I think what you're referring to is actual being able to "tamper-proof" a deployment, which includes avoiding human error. This is enough motivation to make this interesting.

Other than embedding a config, would you be able to accept a case where we cryptographically sign a config file, and verify it when the app loads? so that any tampering or change from what its supposed to be will not allow you to run the app.

[jurukode]

@jondot That's should be fine. But curious, if we sign the config file, is your previous statement still valid?

@jurukode i'm not sure about config files being embedded yet, because they are config files -- they are supposed to be changed/tweaked/etc.

If no, why we still need to separate the file instead embed it?