On Tue, Jul 24, 2018 at 5:48 PM, Brad Warren <b...@eff.org> wrote: > On Jul 23, 2018, at 6:52 PM, Chris Jerdonek <chris.jerdo...@gmail.com> > wrote: > > 2) I don't know how Certbot is architected, but would it be possible > to put the "meat" of Certbot inside a Docker container (ideally > including most of the non-Python dependencies), and then have a much > lighter-weight Python application (with fewer dependencies) running > outside of Docker, and that calls the application inside the Docker > container when it needs to do stuff? > > Maybe. Currently each method of performing the domain validation required to > get a certificate and the support for installing the certificate in > different servers is implemented by a plugin to Certbot. These plugins > implement a class with a certain interface which it registers as a > setuptools entry_point. At runtime, Certbot picks the class type desired by > the user, creates an instance of it, and calls its methods as necessary to > obtain a certificate, install it, etc. Most of these plugins make use of > code in Certbot’s modules that implement common functionality to simplify > plugin development. > > This architecture seems like the opposite of what you’re proposing as > Certbot is calling the plugin as needed rather than the other way around, > but we’re certainly open to the possibility of changing things to make it > easier to distribute Certbot. Are you aware of another significantly sized > project that is structured in this way?
Well, I think I'm just suggesting the idea of exposing the "meat" of Certbot as some kind of service, with the service running inside a Docker container. In that sense, any project using multiple Docker containers can be thought of as using an architecture like this (where each container is providing some piece of the functionality). Depending on your needs, the "service" could potentially be as simple as exposing it only via a command-line API. For example, in the case of Certbot, Augeas could be installed inside the Docker container (responsible for parsing and transforming Apache configuration files), and the master client / orchestration piece could be running natively on the machine. When the master client needs to transform an Apache configuration file, it could pass it to the service running inside the Docker container and get back the output. With your plug-in system, it might / probably need to be the case that installing a plug-in would require installing pieces in both the client and service sides (e.g. to get the advantage of keeping complex dependencies inside Docker), with the division that I've described. --Chris -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/MPISFYDL2BMJ454CDSO4QQ2W5WZP7PP4/
