> I don't have a solution or advice to contribute, but I hope I can > spur along some more discussion on the issue. > > We struggle with the problem of pets versus cattle also. > > We have a farm of pets right now. > > Our team is still evaluating at what level in our infrastructure our > tomcat servers will live. >
Here are some notes how *we* do it: > Tomcat is its own container server, able to deploy and undeploy > multiple apps all by itself. Making docker containers of tomcats > which will then run multiple webapps-- would we deploy a whole > container, pre-loaded with war files? That gives us the power of > docker but eliminates the power of tomcat's own deployment. We think of it as "application containers", not "tomcat containers". So yes, we don't use tomcat's deployment powers anymore. > Do we > create empty tomcat docker containers and fill them with warfiles > once they are running? We package tomcat, app and app-specific-tomcat-config in one image. Deploying a new version of an app means we deploy the whole image. Warfiles are not deployed anymore. > That gives us long-running docker containers > which, from what I understand, misses the point of docker. We do use long-running docker containers. > Or do we > go old school and use chef/puppet/ansible to create cattle servers > in our private cloud without docker altogether. They will be long- > running, but we will likely pay a price at server creation time. We were thinking about that, too. But we concluded that maintaining our tomcats and apps with those tools is too hard for us. But actually we use puppet to run containers. Regards, Christoph This Email was scanned by Sophos Anti Virus
