Re: CherryPy official docker image
Sviatoslav Sydorenko <[email protected]> Wed, 21 Mar 2018 03:51:42 -0700 (PDT)
| Newsgroups | gmane.comp.python.cherrypy |
|---|---|
| Message-ID | <[email protected]> |
JFYI: there's a PR hanging related to dockerizing tutorial https://github.com/cherrypy/cherrypy/pull/1634 Take part if you're interested четвер, 7 травня 2015 р. 10:34:13 UTC+2 користувач Steve Hopkins написав: > > Hello Sylvain, > > My development work is mainly scripting and simple tooling so I openly > welcome other opinions. Here are my thoughts based off your bullets. > > * For distribution use default/latest ubuntu with a slim tag using debian. > Going for a micro distro like busybox can create headaches down the road. I > like to play the how-small-can-I-go game too, but really docker size issues > come down to efficient use of the same base image in your environment. If > you're using the same base you only need additional storage for the extra > layers. The initial hit on download time/space only happens once per docker > node. > * Running the app from cherryd sounds fine to me. > * I don't feel virtualenv belongs in the container; feel free to persuade > me otherwise. > * A "sane" default directory structure sounds like a good idea. The init > script can also look for environment vars overriding this (e.g. docker run > -d -e APP_BASE=/var/www cherrypy) > > The multi-tier architecture you mention in the end can be addressed by > examples in the README and doesn't need to be a focus of the containers > themselves. We can provide example commands and docker-compose.yml to meet > the data and proxy layer needs of most container consumers. > > Saaj brings up a lot of good points, especially considerations that fall > more on those responsible for the implementation of the product > (operations/ops). As mentioned already, I don't see those in the scope of a > base container project either. > > There are a lot of great images on docker hub not under the official > branch. I think it would be good to focus on providing some images meeting > a few different use cases then temperature check feedback and see where > things go. I see three images already based of this thread and the one from > linkedin. > > * CherryPy base. Keep the tags simple like debian/ubuntu, python version > and onbuild. > * Something like Saaj's cherrypy-webapp-skeleton with templates and/or > examples like essential CherryPy things :) > * CherryPy based testing suite as Saaj defines in his post. > > Thoughts? > > > On Friday, March 6, 2015 at 8:21:06 AM UTC-7, Sylvain Hellegouarch wrote: >> >> Hi folks, >> >> As discussed in the recent saaj's status update thread, I could create an >> official docker image for CherryPy. As saaj mentioned, this might not be >> that useful considering how easy it is to install CherryPy. Yet, docker >> images are quickly becoming the default unit for distributing applications. >> I think it'd be dandy if we had an official image hosted on Docker hub. >> >> >> http://blog.docker.com/2015/03/thirteen-new-official-repositories-added-in-january-and-february/ >> >> I can definitely create one but I would like your feedback in regards to >> what it should contain: >> >> * which Linux distribution would you rather we go for? Unfortunately, for >> now base images are fat (around 100 or 200Mb and whenever you start >> installing Python they grow very quickly. This is the time I wish we could >> write Go binaries so that you don't have to drag 500Mb of dependencies to >> run a stupid Python script). >> * should we run the app via cherryd? >> * should we create a venv with cherrypy in it rather than a default >> distribution? >> * should we specify a certain directory structure to host particular >> files (like having a /etcd/cherrypy for instance?) >> >> In the end, we'd want to support a basic multi-tier architecture: >> >> * a docker container running the database >> * a docker container running a CP app >> * a docker container serving static content >> * a docker container to proxy/load balance >> >> Basically, each service in its container. This means, we wouldn't want an >> image doing more than simply running the logic. >> We also want an image that is simple to maintain and, keeping in the true >> CherryPy's philosophy, should stay out of your way as best as possible! >> >> Any feedback would be appreciated :) >> -- >> - Sylvain >> http://www.defuze.org >> http://twitter.com/lawouach >> > -- You received this message because you are subscribed to the Google Groups "cherrypy-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cherrypy-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected] To post to this group, send email to cherrypy-users-/JYPxA39Uh5TLH3MbocFF+G/[email protected] Visit this group at https://groups.google.com/group/cherrypy-users. For more options, visit https://groups.google.com/d/optout.