Relationship between snaps and containers, if any
Gustavo Niemeyer
gustavo.niemeyer at canonical.com
Thu Jan 26 11:29:30 UTC 2017
It's similar.. it's actually a bit closer to just running a normal process
multiple times than Docker is. For example, commands from the snap are in
your local path, the child/parent process relationship is the traditional
one instead of being the child of a daemon, and so on.
Even then, the processes live in a confined world, with its boundaries
defined by which interface connections are established.
On Thu, Jan 26, 2017 at 4:44 AM, Luther Goh Lu Feng <elfgoh at yahoo.com>
wrote:
> Thanks Mark, your explanation is clear. But I am also thinking along
> similar lines to Gustavo's suggestion of running a snap multiple times, and
> wondering if that is the same as having multiple docker processes.
>
>
> -- Luther
>
> On Wednesday, January 25, 2017 10:13 PM, Gustavo Niemeyer <
> gustavo.niemeyer at canonical.com> wrote:
>
>
>
>
> Interesting.. I actually don't see that line between snaps and Docker.
> Just like you can run "docker run mysql" several times, one may run
> "mysnap.mysql" several times. In both cases the daemon will be visible to
> the external world via a separate port of the local host's public IP
> address. In both cases mysql will be isolated from the local environment by
> confinement.
>
> It's even a bit more convenient to do that using a snap. Easier to manage
> the process on a systemd unit, for example, since the mysql process will
> indeed be a child of systemd/etc instead of a child of the docker daemon.
>
>
>
> On Wed, Jan 25, 2017 at 11:51 AM, Mark Shuttleworth <mark at ubuntu.com>
> wrote:
>
>
> >The best way to think of this is to know that snaps are GREAT when you
> >have a precise 1:1 relationship between "machines" and "running
> >instances". And Docker is GREAT when you want an elastic relationship.
> >So for example, if you want a MySQL "appliance" on a device, there will
> >only ever be 1 MySQL instance on that device, you want a snap. If you
> >want a cluster where there may be 1-many instances of MySQl on each
> >actual machine or VM, then you want Docker.
> >
> >The reason for this is that Docker gives each running process its own IP
> >address. That's perfect for the hyper-elastic case - each extra MySQSL
> >is just another IP address to talk to. But if you have a machine where
> >you already have an IP address and all you want is a MySQL there then a
> >snap will be easier.
> >
> >This is why a snap of the Docker daemon makes such sense - in your
> >cluster, you want exactly one copy of Docker itself running on each
> >machine, and that is best pulled in as a snap. That docker process then
> >manages an arbitrary number of docker processes on each machine.
> >
> >Make sense?
> >Mark
> >
> >
> >
> >
> >
> >--
> >Snapcraft mailing list
> >Snapcraft at lists.snapcraft.io
> >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/snapcraft
> >
>
>
> --
>
> gustavo @ http://niemeyer.net
>
--
gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170126/cc2d0096/attachment.html>
More information about the Snapcraft
mailing list