with the announcement of cooperation with Docker, I have been thinking
what is the position of Foreman project in the Linux containers world.
Support of docker in libvirt has been announced and also dropping
requirement on AuFS which will bring Docker soon to Fedora and RHEL.
If my understanding of Docker correct, installation and configuration is
now task of developers, instead of operations. In some talk, a guy from
dotCloud said "Docker works great with tools like Puppet or Chef". That
means for me that developers will be using Puppet/Chef to provision
containers and operations are just taking them and running them
properly. Correct me if I am wrong here, I was only reading around and
watching some slides last night.
Now, the question is, where Foreman stands in this scenario.
It looks like the best fit might be to support creation of the
containers plus the deployment which is quite easy. The Docker API seems
to be clean (REST) and the CLI client only use this API so it should be
everything possible.
I expect the libvirt support to be limited only to starting/stopping
containers. If we want to support creation of containers (which is the
best thing since Foreman is are good in Puppet), then we need to talk to
the API directly. There are few Ruby libraries for that out there.
IMHO… anything that speeds up / improves installation is a good thing.
Plus, this should help development as you could have many containers on
the same machine without the vm overhead.
– bk
···
On 09/20/2013 05:12 AM, Lukas Zapletal wrote:
> Hello,
>
> with the announcement of cooperation with Docker, I have been thinking
> what is the position of Foreman project in the Linux containers world.
> Support of docker in libvirt has been announced and also dropping
> requirement on AuFS which will bring Docker soon to Fedora and RHEL.
>
> http://blog.docker.io/2013/09/red-hat-and-docker-collaborate/
>
> If my understanding of Docker correct, installation and configuration is
> now task of developers, instead of operations. In some talk, a guy from
> dotCloud said "Docker works great with tools like Puppet or Chef". That
> means for me that developers will be using Puppet/Chef to provision
> containers and operations are just taking them and running them
> properly. Correct me if I am wrong here, I was only reading around and
> watching some slides last night.
>
> Now, the question is, where Foreman stands in this scenario.
>
> It looks like the best fit might be to support creation of the
> containers plus the deployment which is quite easy. The Docker API seems
> to be clean (REST) and the CLI client only use this API so it should be
> everything possible.
>
> I expect the libvirt support to be limited only to starting/stopping
> containers. If we want to support creation of containers (which is the
> best thing since Foreman is are good in Puppet), then we need to talk to
> the API directly. There are few Ruby libraries for that out there.
>
> Ideas? Comments?
>
Yep, I was more like where Foreman stands when its users are on
containers, but you are absolutely right.
In that regard, we should maybe start with phase one, and offer at least
appliances with Katello / Foreman installed. I can imagine users not
starting with installation because the find it (for any reason) complex.
Phase two could be - containers with pre-installed projects.
Just a thought…
···
On Fri, Sep 20, 2013 at 08:06:34AM -0400, Bryan Kearney wrote:
> On 09/20/2013 05:12 AM, Lukas Zapletal wrote:
> >
> >Ideas? Comments?
> >
> IMHO.. anything that speeds up / improves installation is a good
> thing. Plus, this should help development as you could have many
> containers on the same machine without the vm overhead.
>
> Hello,
>
> with the announcement of cooperation with Docker, I have been thinking
> what is the position of Foreman project in the Linux containers world.
> Support of docker in libvirt has been announced and also dropping
> requirement on AuFS which will bring Docker soon to Fedora and RHEL.
>
> http://blog.docker.io/2013/09/red-hat-and-docker-collaborate/
>
> If my understanding of Docker correct, installation and configuration is
> now task of developers, instead of operations. In some talk, a guy from
> dotCloud said "Docker works great with tools like Puppet or Chef". That
> means for me that developers will be using Puppet/Chef to provision
> containers and operations are just taking them and running them
> properly. Correct me if I am wrong here, I was only reading around and
> watching some slides last night.
I'm also going off of documentation rather than using it.
> Now, the question is, where Foreman stands in this scenario.
>
> It looks like the best fit might be to support creation of the
> containers plus the deployment which is quite easy. The Docker API seems
> to be clean (REST) and the CLI client only use this API so it should be
> everything possible.
>
> I expect the libvirt support to be limited only to starting/stopping
> containers. If we want to support creation of containers (which is the
> best thing since Foreman is are good in Puppet), then we need to talk to
> the API directly. There are few Ruby libraries for that out there.
>
> Ideas? Comments?
I agree that Foreman could work well for creating images, replacing use
of commands in the Dockerfile for building with a Puppet (etc) agent. http://docs.docker.io/en/latest/use/builder/
But I think Foreman could also be used effectively for deployment. We
already have the concept of compute resources running hosts which are
launched from images, so this could just as easily map to a Docker host
as a compute resource, with new hosts launched off of Docker images.
One way I imagine it could work is:
you set up host groups representing the image types you want and
Puppet classes attached
you apply the garethr/docker Puppet module to a host, it becomes a
Docker-enabled host and self-registers to Foreman as a Docker compute
resource
to build images, you have a special process that launches the Docker
build process with a Puppet agent based off of the predefined host
group, then the built images get associated to the host groups they were
based on
launch new "hosts" on the Docker compute resource, select the host
group (for the role) and the associated image is used
Or maybe that's too tied to Foreman's existing processes and concepts
(like "hosts" when it's just a container) and we need something a bit
more forward-thinking?
I wonder if it makes any sense to continuously manage a container with
something like Puppet, or if you just want a way to know when it's out
of sync so it can be destroyed and reprovisioned from the latest image.
···
On Fri, Sep 20, 2013 at 07:05:48PM +0100, Dominic Cleal wrote:
> I wonder if it makes any sense to continuously manage a container with
> something like Puppet, or if you just want a way to know when it's out
> of sync so it can be destroyed and reprovisioned from the latest image.
Long term, provisioning a container and managing a container would be a
big win.
– bk
···
On 09/24/2013 08:18 AM, Lukas Zapletal wrote:
> On Fri, Sep 20, 2013 at 07:05:48PM +0100, Dominic Cleal wrote:
>> I wonder if it makes any sense to continuously manage a container with
>> something like Puppet, or if you just want a way to know when it's out
>> of sync so it can be destroyed and reprovisioned from the latest image.
>
> That is the biggest question here.
>
We are already looking at containers here, I have been a huge fan of
container and used to manage 300 Virtuozzo containers at a hosting company,
I have also used BSD Jails, Solaris Zones and OpenVZ. Linux containers are
great but they a long way to go before they are production ready. The live
migration feature I used with Virtuozzo and OpenVZ is still a twinkle in
the devs eye. We would use both long term containers and quick and dirty
disposable containers for testing carving up XL AWS instances. This would
tie in with our existing processes where we provision with Foreman then
snap shot AWS instances based on host groups. Our autoscaling is managed
with Sensu monitoring triggering a call to Foreman's API. Any changes since
the snapshot are picked up by Puppet's first run before being added to an
ELB when we know the instance is good.
I realize it off topic and a low priority but I would love to be able to
manage EIP, ELB and AWS volume management assignment directly through
Foreman as well.
Jim
···
On 24 September 2013 13:30, Bryan Kearney wrote:
On 09/24/2013 08:18 AM, Lukas Zapletal wrote:
On Fri, Sep 20, 2013 at 07:05:48PM +0100, Dominic Cleal wrote:
I wonder if it makes any sense to continuously manage a container with
something like Puppet, or if you just want a way to know when it’s out
of sync so it can be destroyed and reprovisioned from the latest image.
That is the biggest question here.
Long term, provisioning a container and managing a container would be a
big win.
wrt AWS volume management, I hacked something with foreman_hooks using the
comment field to attach or resize volumes at build time. Ive been meaning
to write it up but havent got around to it. Also working on multiple ips in
a VPC and eip attachment.
···
On Tuesday, September 24, 2013 7:06:24 AM UTC-7, Paradoxbound wrote:
>
> We are already looking at containers here, I have been a huge fan of
> container and used to manage 300 Virtuozzo containers at a hosting company,
> I have also used BSD Jails, Solaris Zones and OpenVZ. Linux containers are
> great but they a long way to go before they are production ready. The live
> migration feature I used with Virtuozzo and OpenVZ is still a twinkle in
> the devs eye. We would use both long term containers and quick and dirty
> disposable containers for testing carving up XL AWS instances. This would
> tie in with our existing processes where we provision with Foreman then
> snap shot AWS instances based on host groups. Our autoscaling is managed
> with Sensu monitoring triggering a call to Foreman's API. Any changes since
> the snapshot are picked up by Puppet's first run before being added to an
> ELB when we know the instance is good.
>
> I realize it off topic and a low priority but I would love to be able to
> manage EIP, ELB and AWS volume management assignment directly through
> Foreman as well.
>
> Jim
>
>
> On 24 September 2013 13:30, Bryan Kearney <bryan....@gmail.com > > wrote:
>
>> On 09/24/2013 08:18 AM, Lukas Zapletal wrote:
>>
>>> On Fri, Sep 20, 2013 at 07:05:48PM +0100, Dominic Cleal wrote:
>>>
>>>> I wonder if it makes any sense to continuously manage a container with
>>>> something like Puppet, or if you just want a way to know when it's out
>>>> of sync so it can be destroyed and reprovisioned from the latest image.
>>>>
>>>
>>> That is the biggest question here.
>>>
>>> Long term, provisioning a container and managing a container would be a
>> big win.
>>
>> -- bk
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev...@**googlegroups.com .
>> For more options, visit https://groups.google.com/**groups/opt_out
>> .
>>
>
>
