Introducing Dockerfile, Config.json (prep), building and pushing docker, auto tagging and auto release creation

[cronventis]

Soo... I have been a little busy and created something to fix #39 and #42 But thats not all.. Let me explain in a little more detail.

Docker

I create a Dockerfile that has two parts. The first part is building the app (npm build), while the second part is the actual production Dockerfile using nginx, that will copy the app from the build stage into a nginx wwwroot. In addition, I created a folder called docker, where two files are located: startup.sh and nginx.conf both files are copied in the production docker image. I'll explain a little further down why. If you want to test the docker build, you can run for example:

docker build -t king-for-kong:local .
docker run -p 8080:8080 king-for-kong:local

config.json

Since this was my plan from the begining, I added the startup.sh script to the Dockerfile, and here is what it does:

Details

So, this script is all about managing a configuration file called `config.json`. The main goal is to make sure that config.json` contains the right configuration values based on certain environment variables. Here's how it works: First, the script checks if `config.json` exists. If it does, it looks at the environment variables to see if any updates are needed. Specifically, it checks if the `KONG_ADMIN_URL` variable is set. If it is, we update `config.json` with the new value. Then, we double-check if `USERNAME`, `PASSWORD`, and `AUTH_TYPE` are all set. If they are, we update `config.json` with these values too. Now, if any of the required environment variables are missing (`USERNAME`, `PASSWORD`, or `AUTH_TYPE`), there will be a friendly error message. It's important to set all of them for everything to work smoothly. On the other hand, if `config.json` doesn't exist yet, we check if the necessary environment variables (`KONG_ADMIN_URL`, `USERNAME`, `PASSWORD`, and `AUTH_TYPE`) are all set. If they are, we create a brand new config.json file with the provided values. However, if only `KONG_ADMIN_URL` is set, we'll create a simpler version of `config.json` with just that value. Now, if none of the required environment variables are set, we'll simply tell you that there's nothing to do. We don't want to mess with things if there's no proper configuration, right? Finally, no matter what changes we made or didn't make, the script wraps up by starting the web server. So, that's the lowdown on how this script manages the `config.json` file and ensures everything is set up correctly for your web server.

So through this, you will be able to start the image with environment variables (eg: KONG_ADMIN_URL) and this will create a config.json in the wwwroot, which can be used by the app itself. There is only one issue: the config.json might contain the password (if you set it using the env var) as clear text! but since I'm guessing that this is a tool only used internally, that could be fine.. Otherwise, If you have an idea how to improve the security, go ahead.

Github Action

Building

So I added you a github action for the main branch (main.yml). In this, I'm doing a couple of things, starting with getting the next release number... This release number will be used for tagging the docker image beeing created. Its basically the same step to build as locally. but in addition to that, the image is beeing pushed into ghcr.io and can then be used by everyone.. Here is an example of my tests: https://github.com/cronventis/king-for-kong/pkgs/container/king-for-kong

Tagging

As you have seen in my example, all those docker images have a version.. I used a plugin called github-tag-action to get the last tag, and whenever there is a new commit to main, it will increase the patch version. unless the commit has something like #minor or #major in the commit message, then it will bump the respective version. This will just create a tag on the repo. but in addition to that, I also added:

Release creation

Once the commit is tagged, i also create a new release using this plugin with the respetive version. It contains a zip with the build-result from inside the docker image and the source code as usual. you can see that here This release will also include infos about the commits that went into the release. If you push multiple commits at once, it will only build the last one.

Fixed code analysis

I also got errors from the code analysis, so I updated the version from v1 to v2.

And that should sum it up....... Lets hear your thoughts... ;)

[cronventis]

I would recommend a squatsch commit, to cleanup my tests.. ;)

[ligreman]

Thanks @cronventis, thats a lot of work!

I'll take a look at it. It'll helps a lot to have some docker images of King. I want to understand all of it (to learn more about it, because is something new to me).

First I'll correct some bugs and then start with the "docker thing" 👍🏻

[cronventis]

I'll take a look at it. It'll helps a lot to have some docker images of King. I want to understand all of it (to learn more about it, because is something new to me).

If you need help understanding or need a more detailed explenation, let me know how I can support.

[jeremyjpj0916]

This is great too, we can start also having docker images for the app! I personally am glad running from source is so easy for now too though.

[ligreman]

@cronventis What was your idea with the USERNAME, PASSWORD and AUTH_TYPE variables in the startup.sh file?

I suppose it is to config the authentication method to get the config JSON file, if the server has some auth enabled. So King will Authorization header type BASIC. But, I don't what is the auth_type parameter objective.

[cronventis]

Actually, I was thinking about a protected kong-admin api...But it realy is not that important.. You can delete that if you dont think it is needed.. Thanks for the merge ;)