11–20 of 29 posts
Are the tests run against the docker image that is going to pushed on passing build?
> As images are pushed into the Docker registry they are versioned using the Jenkins build number.
Why not use the git SHA ?
What's the best practice for accessing persistent data from a database system that's in a Docker container?
Typically, you want to supply the container with a mount point that is outside the container. This way, if the container is replaced, your data isn't impacted.
In a classic "apps run on a known instance" model, when the instance starts having performance issues, I can ssh to it and use the usual tools (iosat, top, atop, netstat, etc...). With docker, how do you correlate instance/docker, and do perf analysis?
I wonder how they log from applications in Docker, we found it to be one of the blockers that kept us from using Docker.
I use Papertrail but if you want something free...just run Logstash + Kibana + Elastic Search. Running a log shipping agent on every docker instance isn't 'free' but it lets you clearly label and manage your logs nicely.
Do you have to take pains to not accidentally log user and secure information to a third party when you use Papertrail?
> Logstash + Kibana + Elastic Search
That seems involved and a long time to set up, but I will check it out. Thanks.
Earlier quoted context omitted.
I use Papertrail but if you want something free...just run Logstash + Kibana + Elastic Search. Running a log shipping agent on every docker instance isn't 'free' but it lets you clearly label and manage your logs nicely.
> I use Papertrail Do you have to take pains to not accidentally log user and secure information to a third party when you use Papertrail? > Logstash + Kibana + Elastic Search That seems involved and a long time to set up, but I will check it out. Thanks.
I only use Papertrail for personal projects that don't have any real security requirements. $7/month is alot less hassle than the time it takes to setup Logstash+Kibana+ES.
However, for anything with security requirements I'd run Logstash+Kibana+ES over a VPN.
Earlier quoted context omitted.
Typically, you want to supply the container with a mount point that is outside the container. This way, if the container is replaced, your data isn't impacted.
So redeploying means switching database to a different docker, and means interruption (thinking of traditional relational DBs here)?
1. Promote B to primary and switch the clients over so that they write to B.
2. Redeploy A, and wait for A's replication to catch up to B.
3. Promote A back to primary and switch the client writes back to A.
4. Redeploy B and wait for B's replication to catch up to A.
5. Have a drink.
Responsible ops practice is to follow this procedure on every deploy, because the failover process has presumably been designed, engineered, rehearsed, and tested in production – as it has to be, because it might happen at any moment during an emergency – whereas the redeployment you're about to do has never been tried in production before and you can never be certain that it isn't going to take down your database server processes for a millisecond or an hour.
Docker doesn't really help or harm this process, though it does subtly encourage it, because the adoption of Docker and the adoption of an immutable-build philosophy often go hand in hand.
If you don't have firm confidence in your database failover procedure, you don't want to host your database in a Docker container.
> Every time we checkin to GitHub, Jenkins is called via a post commit hook and builds, unit tests, and integration tests our code as is typical in a continuous integration setup. Are the tests run against the docker image that is going to pushed on passing build? > As images are pushed into the Docker registry they are versioned using the Jenkins build number. Why not use the git SHA ?
Because you want your version numbers to make semantic sense. Your entire team intuitively understands that version 4137 is more recent than version 4134, that version 3527 is in the distant past, and that going from version 4138 to version 4137 is a sensible rollback, whereas going from version 4138 to version 4136 is either a mistake or a response to a major failure of QA.
Similarly, resist the urge to name servers generically. "There's something wrong with web-347!" is a sentence that you can shout across a crowded ops war room, whereas "web-129.22.8.44" or "web-a781bc23" or "instance i347bd944" are much harder to pronounce and much easier to typo.
How do you deal with performance problem? In a classic "apps run on a known instance" model, when the instance starts having performance issues, I can ssh to it and use the usual tools (iosat, top, atop, netstat, etc...). With docker, how do you correlate instance/docker, and do perf analysis?