> As mentioned, I removed all containers and images as stated in the steps to reproduce, including the consul and vault instances. On the second attempt to build and run the dockerfile, the previous container instances of consul and vault have been wiped. This time when bringing up the containers by calling the up command, the Initialize Vault step is skipped and the vault_key_token file is not produced inside the parent container.
When you run `pygluu-compose up` command for the first time, Consul and Vault will be initialized and its state will be saved into volumes at `/usr/local/gluu/volumes`. If you re-deploy Consul and Vault, they will load data/states/etc from those volumes. This is why Vault is not re-initialized and there's no process to save key/token into `/usr/local/gluu/vault_key_token.txt` again.
- remove existing Consul and Vault containers
- remove existing Consul and Vault volumes (check `/usr/local/gluu/volumes/consul` and `/usr/local/gluu/vault` in host filesystem)
- ensure your working directory (`/usr/local/gluu`) can be mounted correctly as volume in host filesystem (because you will need to persist files there, including `vault_key_token.txt`)
- redeploy containers
> This seems like a bug because these are freshly created containers and images and it is not running the same way depending on if Docker was just restarted or not. Its almost like there is something being cached in docker in between build and run attempts.
Not sure if this is a bug because we heavily tested `pygluu-compose` on host directly.
> We are exploring alternative methods of standing up a Gluu server instance that do not involve the pygluu-compose method now based on your documentation.
You can use our Kubernetes-based installation.