71–80 of 85 posts
I've adopted Docker in my main dev workflow and I'm super happy. And the 4 or 5 co-workers I showed how it works have since adopted it too. I think it's very possible it's just you.
Docker certainly has its pain points but I've actually really enjoyed working it into our build and deployment process. The command syntax is sometimes a bit clunky but they are making regular improvements. Not to repeat lgbr, but the registry is pretty easy to get running. I had some problems initially, but it was mostly because I didn't really understand how to use a container all that well. That sounds somewhat si…
I understand they want the public index to "always work", but the requirement to tag images with FQDN for docker to even try to use a separate registry breaks a lot of a very common use cases, such as transparent caching and mirroring of images.
Earlier quoted context omitted.
> To run unit tests which rely on certain hosts to resolve to 127.0.0.1. If you are unit testing DNS infrastructure, shouldn't you mock DNS things?
I'm not unit testing DNS infrastructure. I'm unit testing an Apache module. I send requests to different virtual hosts on 127.0.0.1:80, and checking whether the responses are what I expect.
I've been waiting for the hype to die down a bit and for the project to stabilise before properly playing with it but, from the outside looking in, I must admit I struggle to see how it's gaining as much attention as it is. I can see the advantage for dev boxes where a developer might want to setup a load of containers on their machine to emulate a staging or production environment. But I don't really understand why…
I setup docker for our server deployments here at lever.co. We deploy our application multiple times a day. We test our changes in our staging environment first, and its important that we deploy the exact same code to production that we tested. Its also important that we can rollback any changes we make. An application-image is the right way to do that. (With compiled dependancies and whatnot). And we could make an O…
with api.settings(**env_vars):
api.run('docker run baseimage sh -c "git pull && cp /src/webapp/settings/paths_docker.py /src/webapp/settings/paths.py"')
d = datetime.datetime.now().strftime('%Y-%m-%d,%H-%M')
# new image from last running container with updates
api.run('docker commit $(docker ps -lq) baseimage:%s' % d)
api.run('docker stop $(docker ps -aq)')
api.run('docker run -d -p 127.0.0.1:8073:8083 baseimage:%s sh runindocker.sh' % d)I've adopted Docker in my main dev workflow and I'm super happy. And the 4 or 5 co-workers I showed how it works have since adopted it too. I think it's very possible it's just you.
Would you mind sharing that work-flow? I'm interested in how this is done, since i have failed to do it on several occasions.
The primary stopper for me is run vs start I think - and persistence of the most recent change I made in an environment.
Earlier quoted context omitted.
What if the mysql server isn't in a docker container or even on the same machine?
then just use environment variables (ENV keyword in Dockerfile or --env param in docker run command)
Libvirt has support for lxc these days, if memory serves. I'd recommend it - docker just seems heavily marketed. What you're mentioning with hosts/resolv etc is a problem that has been "solved" with tools like etcd and zookeeper as someone else mentioned. I tried docker with a couple of things, and found that it is an environment that (at the time I experienced it, maybe six months ago) was so unhelpful as to appear…
But this is really a normal aspect of a healthy, technological ecosphere. Kids grow up, they get interested in a subject, they ignore all the prior art, and they get on with doing things that they think are interesting - including fixing 'whats broke' (which often translates to 'whats not well-known') .. all technology culture suffers this factor. Why complain: its a principle driver of the state of the art, because only the good technology survives this onslaught. If its known-about in the first place, it rarely gets re-invented.
Libvirt has support for lxc these days, if memory serves. I'd recommend it - docker just seems heavily marketed. What you're mentioning with hosts/resolv etc is a problem that has been "solved" with tools like etcd and zookeeper as someone else mentioned. I tried docker with a couple of things, and found that it is an environment that (at the time I experienced it, maybe six months ago) was so unhelpful as to appear…
I agree that Docker is suck sometimes, but most of times are because existing application is not built in a way that docker expects. I am optimistic that more are more applications are designed to be used for container environment.