1) How can I run several different branches on the staging server?
2) How would I set up the DB evolution system to make sure it always has appropriate DB for each branch?
This depends on how much you expect your DB to scale. You can get pretty crazy with methods to clone database data but typically you will want a master copy that you do not ...
Since the response is Access denied for user so the port and the ip address is correct.
I guess the only issue as @James said will be in the permission, you have to allow root access to mysql from elk and php containers, you can do it in easy way but it's not secure:
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password';
%: mean match all
I'd argue that this isn't actually about staging servers. A staging server closely mimics the production environment, and is where a release goes immediately prior to going to production. A feature branch that hasn't been merged into master is not going to be released directly to production, so it should not go on a staging server.
If we reframe the ...
Your golang api should be included in the compose file and added to the same network.
It also looks like when you run the golang api that you are adding it to a network other than backend, which is the network that is created in your compose file.
That's a known issue .. since image layers are built using containers, data saved to folders does not make it to the next layer or your final container
Removing intermediate container b3ff83bbf273
If you want data to persist between updated containers you have to manually map data to the host outside the container-specific mount points.
For example, when ...
What would be the best way to share ports among the containers?
You don't really "share" ports between containers. Instead, you want to create network and attach each container to that network. Each container gets a network alias (essentially a hostname) that you can use to hit the service.
$ docker network create foo
$ docker run --network=foo --...
There shouldn't be any reason why you can't. I think that the issue would be in getting the memory management correct on the host. The orchestration would be the same.
Here's some resources:
In addition to connecting app container with same backend network, you will also need to fix MySQL host parameter in connection string.
Looking at main function you have MySQL host set to localhost
serverName := "localhost:3306"
However, MySQL is not listening at lcoalhost of appc container you will need to change it to MySQL service name in compose file, ...
I think you could achieve something similar by first running Terraform against your RDS resources, and then running Terraform again on all resources.
On your first pass, you can use -target option to target only a subset of the resources. (ie. RDS resources).
Be aware that using this option is not recommended in Terraform docs. If I were you, I would use ...
Without seeing the specific error it looks like the container's runtime process is either crashing or exiting. When a docker container's runtime process exits the container stops.
You can get more information about the specific error by using the docker logs command:
docker logs 92455a993a54
On top of protecting your root account as best as you can, you should be able to reduce the risk of such resource deletion if you have more than 1 resource to protect.
For example if all AWS resources you had to protect were 2 RDS database servers, you could create 2 other accounts that have access to only copy the snapshots of one of your database servers ...
First, confirm that the container is actually listening for connections and has properly bound to the interface. If not, you probably need to fix the bind-address= and/or port= directives in your my.cnf.
Otherwise, you probably have an issue with your GRANTs. Check that the IP/subnet is correctly authorized in the mysql.user table with the command