search

tnc1997 / azure-app-configuration-emulator

Please note that Emulator for Azure App Configuration is unofficial and not endorsed by Microsoft.
MIT License
3 stars 3 forks source link

Add docker-compose file with better local debugging support #46

Closed paulirwin closed 7 months ago

paulirwin commented 7 months ago

Describe the change This adds a docker-compose.yml file and updates the README to simplify running the app to just docker-compose up -d. This should greatly simplify the experience for new users running the emulator. The compose file also uses named volumes for easy persistence and access from the host for the keypair and database files.

In order to better support local debugging without having to have access to system folders, this uses an environment variable when running in Docker for the database and cert/key files, but defaults to a "data" folder within the repo so that the IDE/CLI does not need special permissions to /var (on macOS/Linux).

Additionally, the openssl command has been moved into keygen.sh which can be run locally for local development, but is also run by the container and is aware of those Docker Compose environment variables, falling back to the local data folder.

Current behavior The instructions to start up the emulator are complex and are not easily repeatable.

New behavior The startup of the emulator is easy with docker-compose up

Additional context Updates README, adds keygen.sh file for easy key generation.

tnc1997 commented 7 months ago

Hi @paulirwin, thank you very much for your contribution!

Given that different teams will be running the emulator differently I would like to keep getting started as is for now.

It is also worth noting that the emulator is still being developed and so there could be breaking changes pre-stable.

paulirwin commented 7 months ago

This change is largely in addition to what already exists. What about if I add back the README instructions for those that don't want to use docker-compose?

tnc1997 commented 7 months ago

I would like to keep getting started as is for now as those steps are simple for people to get started with the emulator.

Different teams will likely have different ways of running the emulator so I would like to keep the README generalised.

paulirwin commented 7 months ago

With all due respect, the following steps are not exactly simple to use:

openssl req -x509 -out ./emulator.crt -keyout ./emulator.key -newkey rsa:2048 -nodes -sha256 -subj '/CN=localhost' -addext 'subjectAltName=DNS:localhost' docker build -f ./src/AzureAppConfigurationEmulator/Dockerfile -t azure-app-configuration-emulator . docker run -e ASPNETCORE_HTTP_PORTS=8080 -e ASPNETCORE_HTTPS_PORTS=8081 -p 8080:8080 -p 8081:8081 -v ./emulator.crt:/usr/local/share/azureappconfigurationemulator/emulator.crt:ro -v ./emulator.key:/usr/local/share/azureappconfigurationemulator/emulator.key:ro azure-app-configuration-emulator-data-potection-keys:/root/.aspnet/DataProtection-Keys azure-app-configuration-emulator

I do not understand how that is simpler than docker-compose up. Can you explain your thinking?

And like I said, I can add back these instructions if you'd prefer, while also having a docker-compose option for those that want a simple command to start it up. I think this helps move in the direction of your goal of "Different teams will likely have different ways of running the emulator" which includes docker-compose and named volumes.

It also is not simple for local debugging to have to grant access for the IDE to /var/lib (on macOS) to run outside of Docker. It is far easier to run in my experience to use a path within the repo where that permission is implicitly granted already. Additionally, this change allows for an environment variable to specify where the keypair/database files are, which better enables your goal of "Different teams will likely have different ways of running the emulator" - something that is hindered with the current hardcoded paths. By making it environment variables, users can set it to any path they want for any way they want to run the app. That said, if you really want those hardcoded paths, I can add that back as a fallback if the env var is not present.

Can we discuss how we can enable these different ways of running the emulator (such as via docker-compose with one simple command) without closing this PR wholesale? If you have feedback on the PR I'm open to addressing it.

tnc1997 commented 7 months ago

To be fair the current approach only requires copying and executing 3 commands (2 if you exclude self-signed certificate generation) and being container-based also means that it is cross-platform.

Enhancing the documentation with other supported environments and scenarios is something that will be done nearer to the stable release of the emulator.