Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Running docker on RHEL #172

Closed
davidreuss opened this Issue · 140 comments
@davidreuss

This issue is meant for tracking dockers status on RHEL (Red Hat Enterprise Linux)

The one main pain-point i believe is AUFS, which isn't directly available on RHEL.

I haven't myself had as much time to play around with it, but i wanted a central location for storing progress/feedback from people trying to get docker running.

@jpetazzo

You might want to try this kernel:
http://get.docker.io/kernels/kernel-3.2.40_grsec_dotcloud-4.x86_64.rpm

Warning: the package is 700MB! I'm sorry, that's what I got when running make rpm on our kernel tree.

This kernel features:

  • grsec (for hardened security)
  • AUFS
  • setns support

I don't have any RHEL/Fedora/CentOS machine around, so I can't test it, but it's compiled with exactly the same .config as our kernels. It is configured to run on bare metal, KVM virtual machines, Xen virtual machines (and therefore supports EC2). It might work on HyperV but I never tested it there.

@shykes
Owner

cc @brianm

@shykes
Owner

Anyone else interested in Red Hat support?

@bfulton

+1

@scrothers

I'm interested in building a proper AUFS RPM against the existing sources, honestly I think having it released to EPEL or something would be best. Future maintanability and development ecosystem and so on.

I'll start researching what this effort will take and open a case and link it to this one.

@mrallen1
@josephglanville

Ideally a DKMS RPM should be built. I am pretty sure RHEL 6 uses DKMS and it will keep AUFS working across kernel upgrades.

@jpetazzo
@josephglanville

DKMS can build any module. It's the same as doing make, make install in the module source directory. (or doing make modules; make modules_install in the kernel source tree).

The only thing that DKMS does for you is automatically rebuild the module against the newly installed kernel so that it has the correct symbols.

@jpetazzo
@josephglanville

Ahh yes you are correct, my mistake. :(

Shame about that, I hope one day AUFS becomes mainline so this doesn't happen sigh.

@timbunce

+1 for RHEL/CentOS

@scrothers

It appears that DKMS will not work for this, as we cannot logically separate the components of AUFS from the Kernel image 100%. It still requires the Kernel image be patched with specific AUFS code.

The only realistic way to include this is to patch it directly into the EL6 upstream Kernel and release that code as buildable. Which is what I'm going to pursue right now. Once it's complete I'll be releasing it on my Github, however a longer term goal may be to operate a specific Kernel for Docker anyway. Include all the new fancy cgroup utils and other filesystems.

Thoughts?

@jpetazzo

If you can point me to the EL6 source tree, I can add it to our kernel build farm (with some luck, our AUFS patch queue will apply neatly; or at least, require only minor work to merge).

FWIW, I recompiled our production kernels without debugging symbols (so now the RPM is just 50MB instead of 700MB):

http://get.docker.io/kernels/kernel-3.2.40_grsec_dotcloud-4.x86_64.rpm

If someone could give it a try, that would be awesome.

@scrothers

Depends, are you using AUFS 3.x? If so the RHEL Kernel won't work, since it's a 2.6.32 Kernel. It'll be missing most of the API/ABI that I'm assuming AUFS 3 requires since it specifically states Kernel 3.0 requirement.

However though, as requested, the current SRPM:
http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-358.2.1.el6.src.rpm

Obviously you can unpack the source using rpm, in the case you're on debian or osx (with brew) or something...

rpm2cpio kernel-blablabla.rpm | cpio -idmv

Also, going to give that Kernel a try now on an EL6 machine.

@scrothers

Yea, there's a lot of depsolving and conflicts in this Kernel you have posted...

Where is the srpm at? I'll be happy to work the spec out.

Ideally, this Kernel wouldn't upgrade or replace the existing RHEL Kernel (so it'll remain updated) it should be supplemental to the RHEL Kernel and updated separately.

Errors here:
https://gist.github.com/stevencrothers/5269833/raw/a42f40f6feb2813fb6a78b4e80cfcb08c1cc525e/gistfile1.txt

I'm going to open a case for this so it can be properly tracked.

@scrothers

For the record, new case is here to track the specific Kernel changes:
docker/docker#253

This case should be made dependent on 253, not sure if that's possible on Github.

@stahnma

It seems like targeting Fedora 18/19 (and thus what will likely become EL7) would be easier/better than working on the 2.6 kernels in EL6.

@shykes
Owner
@pdf

OverlayFS is attempting (again) acceptance for merge into mainline 3.10, but it still seems unlikely at this point, since Al Viro (the VFS maintainer) doesn't like some chunks of the design (primarily use of xattrs for opaques), which seems to be causing a little friction since Miklos is somewhat attached to the idea for portability (FWIW, I kind of agree with Miklos here).

That said, it's already included in the standard kernel patchsets for at least Ubuntu and SuSE, maybe others. and as @shykes points out, aufs is soon to be dropped for Ubuntu so some decision here will have to be made.

@jpetazzo
@dmacvicar

I just hacked support for overlayfs, which is is already on the SUSE and Ubuntu kernels, and probably the only one that will make it to upstream. I can't get the tests to pass because an unmount fails in the test. However I can run the container and docker diff seems to be working.
https://github.com/dmacvicar/docker/tree/feature_overlayfs

//cc @flavio @silviomoioli

@kstaken

@dmacvicar Did you change FILESYSTEM_MAX_STACK_DEPTH in your kernel to allow overlayfs to stack more than 2 layers?

edit: just noticed this limit may not apply on opensuse if they don't have that check in their version of overlayfs. On ubuntu FILESYSTEM_MAX_STACK_DEPTH is 2 so mounting a stack a b c d will fail when you go to mount d.

@dmacvicar

@kstaken Mmmm... I only tried with 3 layers so you may be right base + 1 + 1 is still in the max range.

I need to check whether our kernel patches also have that limit.

@dmacvicar

@kstaken you are completely right

May 28 10:21:47 piscola kernel: overlayfs: maximum fs stacking depth exceeded

I oversaw that. Documentation says "The lower filesystem can even be another overlayfs", but did not mention any limits. ARGH.

I would guess for docker the main usecase would be to have an image and keep the changes of the image separate, and then commit them to another image. Are more layers at the same time useful?
Because then we could introduce the limit to docker itself, when using overlayfs.

@dmacvicar

@kstaken I talked to Miklos (overlayfs author) as he work for us, and he confirmed that there is a limit to avoid a kernel stack overflow. He may look into adding arbitrary layers in the future, may be after it is included in the mainline kernel.
The question is whether docker really needs so many layers?

@kstaken

I'm new to docker but I believe more layers at the same time is core to the way docker is intended to work.

The base image works but using a random image from the registry hits the limit.

docker run mbkan/lamp ps aux
2013/05/28 17:04:17 error: Error starting container b6a38d3e5dbc: Unable to mount using overlayfs

in syslog.

May 28 17:04:17 precise64 kernel: [111971.681350] overlayfs: maximum fs stacking depth exceeded

Is it pretty likely overlayfs is going to make it into the mainline kernel?

@abohne

+1 for EL support. I think targeting EL7 may be a more worthwhile effort than trying to move heaven and earth to get it working on EL6.

@nehaldattani

In case someone want to try, I have documented the steps for fedora 18 at http://neh.al/?p=1

@NuxRo

+1 for EL6 support. Also if you need alternative kernels you can contact elrepo.org who specialises in alt kernels and extra drivers for RHEL and clones.

+1 also for using a properly supported filesystem such as btrfs.

@beders

+1 for Redhat/CentOS support

@sontek

+1 For Redhat support

@Mistobaan

+1 for RH / Centos 6.4 support

@jdoss

+1 for RH / Centos 6 support

@mariocar

+1 for RHEL/CentOS 6+ support

@rickysaltzer

+1 For RHEL/Centos 6.x support

@tamsky

++ for Centos6/RHEL6 support

@gbraad

+1

@perdurabo93

Absolutely +1. Docker isn't all that useful when the majority of commercial development happens on RHEL/Centos/Fedora/Oracle Linux based distros.

@thijsterlouw

+1 otherwise our operations guys will block us from working with Docker. Need a clear upgrade path to RHEL7 and preferably on RHEL6.

@velniukas
@hura

+1

@cyberoblivion

+1 For Redhat support

@mfojtik

+1

@hanleybrand

+1 for RHEL 6 - that's my employer's approved linux server distro - ubuntu & others are non starters in our data center.

@blalor

+1 for RHEL/CentOS.

@voltagex

Can people please let me know if using a newer kernel from elRepo is not an option for them?

@velniukas
@mhitza

+1 Fedora

@gregretkowski

I just did a write-up on how to install docker on CentOS / RHEL 6. The kernel Jérôme posted works great, you just need to remove the kernel-firmware package first.

http://blog.rage.net/2013/08/04/installing-docker-on-centos-6/

Jérôme, any chance of publishing a newer kernel RPM? All the docker docs say we should be using 3.8. I'll update my blog post with the newer kernel if one comes available.

@voltagex
@gbraad

Ideally no alternative kernels should be used: people use Red Hat and buy a support contract for a reason. Installing an alternative, non-supported kernel, undermines the idea of running such a distribution. And please, do not compare Fedora and RHEL (CentOS, Scientific Linux, etc) to be the same. For Fedora the situation is different (more experimental in nature and not often deployed in a production environment)

@velniukas
@gregretkowski

Bummed for y'all locked into a support contract like that. The blog post above will be helpful for all the organizations (like several that I've worked with) who already have a large install base and in-house expertise with CentOS (or RHEL) and want to deploy docker w/o changing over to Ubuntu. There are many organizations who have CentOS or RHEL but are self-supporting and have the option to swap out their kernels if need-be.

I don't know that there's going to be a way to have docker have acceptable performance w/o having a layered filesystem that is implemented at the kernel level.

@gbraad

Even if you are self-supporting you are not always able (or want) to install your own kernels. Take for example the amount of deployed CentOS installs in the cloud as a VPS. However, most often these have unmodified kernels provided by the hoster. Most often they disable SELinux, but leave the kernel intact... but unfortunately you can not install your own on many of these. The offered support for filesystem types is limited to a few on RHEL, but you could consider the 'tech preview' status btrfs or zfs for now?

@velniukas
@pdf
pdf commented

@gregretkowski

The blog post above will be helpful for all the organizations (like several that I've worked with) who already have a large install base and in-house expertise with CentOS (or RHEL) and want to deploy docker w/o changing over to Ubuntu. There are many organizations who have CentOS or RHEL but are self-supporting and have the option to swap out their kernels if need-be.

The whole point of RHEL is that it comes with support, running unsupported code will invalidate your support contract, and defeats the purpose in any case.

And, as said earlier, AUFS is being dropped from Ubuntu anyway, so soon there will be zero supported distributions without running modified kernels. And as others have said, VPSs also frequently disallow modifying the kernel.

So, a decision to move to a different layered FS with better (any) cross-distro support is going to be a requirement for Docker to continue (start?) being useful for most people.

@sontek

Is there a good document on why AuFS is so bad? What alternatives are going to be supported? I'd also like to see docker support for Fedora, should I create another ticket for that?

@gbraad

OFF-TOPIC: @velniukas I have interest

@pdf
pdf commented

@sontek

Is there a good document on why AuFS is so bad? What alternatives are going to be supported? I'd also like to see docker support for Fedora, should I create another ticket for that?

AUFS is a large, complex patch that must be applied to the kernel, because it is not (and will not be, AFAICT) merged into the mainline kernel. As such, support relies on various distributions carrying the patch in their official kernel package for it to be supported on that distro. Some have never carried the patch, the rest are ditching AUFS in favour of some of the other projects that implement similar functionality, because carrying such a large patch adds significant maintenance and support overhead.

@voltagex
@kencochrane
Owner

@jpetazzo you were mentioned in the thread, not sure if you saw it, pinging just in case.

@jpetazzo
@bflad
@mrallen1

@jpetazzo I'd prefer dev resources go into BTRFS rather than a 3.8 kernel RPM. Most environments I work in, loading a kernel not released by RH is a non-starter.

@NuxRo

+1 to what mrallen1 said, invest more time in getting it to run on BTRFS which is supported by all distros.

@mhitza

+1 on rather focusing on BTRFS support, I, as others have said as well, am hesitant to load a different kernel than the one provided in the default repo.

@shykes
Owner
@smetj

+1 for dedicating resources to API development, The effort and maintenance in providing a patched kernel RPM isn't worth it.

@devinus

What's the Btrfs story on Centos 6.4?

@devinus

I'm not sure how some of you will sell using Btrfs on RHEL if you can't sell using a custom kernel RPM.

Btrfs is not a production quality file system at this point. With Red Hat Enterprise Linux 6 it is at a tech preview stage and as such is only being built for Intel 64 and AMD64.

Am I missing some context? Is Btrfs going to be supported on RHEL 7 or something?

@NuxRo

Devinus,

BTRFS is available in EL6 (as technology preview, but still, available). Changing the kernel kind of kills it for me (and many others).

@devinus

@NuxRo Understood, but with Redhat actively discouraging production use of Btrfs ("Btrfs is not a production quality file system at this point"), I'm just curious how you guys plan to sell to your enterprises on it if you can't sell them on a custom kernel.

@davidreuss

@devinus BTRFS is slated for RHEL 7 (per http://www.internetnews.com/blog/skerner/red-hat-enterprise-linux-7-to-features-btrfs.html), which makes it a more viable solution going forward, and as far as i'm aware RHEL 7 is slated for second half of 2013. Since docker itself isn't deemed production ready (as per http://blog.docker.io/2013/07/docker-0-5-0-external-volumes-advanced-networking-self-hosted-registry/#production_ready), a BTRFS supported RHEL 7 might be the first non-major-hackish solution for running docker, which i believe a lot of RHEL users would be quite excited to see realized, myself included.

(I think even LXC might be missing some stuff, since it's also a tech preview, but is also slated for a more proper release/support in RHEL 7)

@devinus

@davidreuss That makes a lot of sense.

On a related note, can anybody explain to me why Btrfs support is needed? What functionality does it replace for AUFS? Something related to COW?

@jdoss

Sorry for a daft question but what is wrong with using ext4? What specifically in AUFS and BTFS does docker require and why was AUFS selected in the first place?

edit: Crap! @devinus just beat me to the same question.

@NuxRo

Yes, I will not be selling anything on EL6 and BTRFS. Also, LXC support is coming in Cloudstack and Openstack so I might not be using Docker at all on EL6 and use that instead.
As Davidreuss says, RHEL7 will enable much more serious use of Docker.

@mrallen1

There's also a use case for docker for deployment in a dev or testing environment where using a non production filesystem might be ok. For places which have "standardized" on CentOS or RHEL 6, getting Ubuntu in the door is hard.

It's a lot easier to spin up a new VM image for building test instances to use BTRFS on CentOS/RHEL than to bring in Ubuntu, build up the OS and then push docker containers on top.

@gregretkowski

@jpetazzo If you throw me your kernel config, and any info you can provide on the steps you took to produce the rpm you've posted I'll build a new kernel rpm w/ the 3.8 kernel for EL.

@jpetazzo
@NuxRo

What's with the grsec dep?

@jpetazzo
@solomonstre
@sciurus

I have a spec file for linux 3.10 with aufs at sciurus/docker-rhel-rpm. I haven't had much time to play with it yet, but this kernel and the lxc userspace (spec file also included) seem to get docker working on CentOS 6. I thought I'd also need aufs-utils, but I didn't package them yet and docker didn't complain that they were missing.

Please take this for a spin and let me know if you see any problems. Even better, fix them and send me a pull request!

If it would be useful, I can try to build and distribute binary RPMs via the OpenSUSE Build Service.

@pdf

Has anyone evaluated using LVM's thinly-provisioned snapshot volumes for docker?

LVM snapshots degrade pretty horribly with depth, because unlike COW-based snapshots, references to changed data must be updated all the way up the snapshot stack on each change.

@sciurus

@pdf I think that's true for traditional LVM snapshots, but not for thinly-provisioned ones.

@pdf

@sciurus looks like you're right (from your link):

The previous implementation of snapshots did this by chaining together lookup tables, and so performance was O(depth). This new implementation uses a single data structure to avoid this degradation with depth. Fragmentation may still be an issue, however, in some scenarios.

Sorry for the noise. I don't know how well thin LVM volumes are tested for ENOSPC though.

@solomonstre
@sciurus

I've added a package of docker itself at sciurus/docker-rhel-rpm. It's extremely simple as I use the precompiled docker binary and reuse the upstart job from Ubuntu. I've started playing with OBS here but am running into problems.

@boffbowsh

As I'm hamstrung by EL5, I'm currently messing around with chroot and unionfs as a way to get docker-like functionality when you 100% trust the code you're trying to run and this is the only way of doing it. UnionFS is working perfectly for me. So why hasn't it been mentioned in the conversation so far?

@jpetazzo

@boffbowsh , excellent news. Question (since I'm absolutely not familiar with UnionFS): does it support multiple layers? Or just one?

@boffbowsh

Yep, multiple layers. Example from my ghetto heroku clone:

unionfs -ocow $OVERLAY_DIR=RW:$SLUG_DIR=RO:$BASE_DIR=RO $MOUNT_DIR
@sciurus

@boffbowsh does the stock EL5 kernel include the UnionFS patches? I can't find the unionfs module or userspace tools on a sample RHEL5 system.

@jpetazzo
@sciurus

@jpetazzo No, it doesn't use FUSE. Aufs actually began as a fork of it; see https://lwn.net/Articles/327738/

@boffbowsh

The instructions I followed to get it up and running use FUSE. I figure UnionFS is "safe" as it seems like the majority of LiveCDs use it.

@nareshv

I have created a centos-6.x repository for docker.io with aufs. Thanks to @sciurus for the kernel spec file.

@NuxRo

Nareshv, that's great, thanks for your effort!

@failshell

Thanks for your kernel RPM. Awesome work. I've been testing it on RHEL 6.4 and it works like a charm.

Also, for those interested, I published a Chef cookbook that takes care of installing and configuring Docker.

https://github.com/failshell/chef-docker

@chenryn

@nehaldattani I try to do the same thing on Fedora19 but when I compile kernel-3.10 with aufs3 patch(3.10 branch too), it failed. Are you try this on fc19?

@nehaldattani

@chenryn : At what point it failed ? Can you load aufs module ?

@chenryn

@nehaldattani
CHECK include/mtd (5 files)
/root/rpmbuild/BUILD/kernel-3.10.0+/user/include/linux/aufs_type.h:23: included file 'linux/limits.h' is not exported
/root/rpmbuild/BUILD/kernel-3.10.0+/user/include/mtd/inftl-user.h:9: included file 'linux/types.h' is not exported
/root/rpmbuild/BUILD/kernel-3.10.0+/user/include/asm-generic/fcntl.h:4: included file 'linux/types.h' is not exported
/root/rpmbuild/BUILD/kernel-3.10.0+/user/include/mtd/mtd-abi.h:23: included file 'linux/types.h' is not exported
make[5]: *** [/root/rpmbuild/BUILD/kernel-3.10.0+/usr/include/linux/.check] Eror 123
make[4]: *** [linux] Error 2

@nehaldattani

@chenryn : Are you using code from kernel.org or the code has been extracted from SRPM ?

@chenryn

@nehaldattani I had both tried the kernel code from git branch 3.10, and from kernel-3.10.7-200.fc19.src.rpm. Got the same result

@nehaldattani

@chenryn : I have created a new F19 vm and applied the aufs patches on kernel 3.10 ( code from kernel.org) and just completed building of kernel rpm with aufs module.

In your case, it seems that all aufs header files are not included properly.

I also found a typo in my post. ( Though you will get a message "cp:ommiting directory .....)

Read "cp include/uapi/linux/ ../linux-2.6/include/uapi/linux/" as "cp include/uapi/linux/aufs_type.h ../linux-2.6/include/uapi/linux/"

Please copy header files as mentioned in my post ( exception is above mentioned file) and give it a try.

Good Luck !!!

@sciurus

@chenryn have you looked at sciurus/docker-rhel-rpm? If your goal is to build a 3.10 kernel with aufs support, you can use my steps there. I've added some more information about this to the README.

@jlk
jlk commented

+1 - Would love to see solid EL6 support. Curious to see where this goes...

@mztriz

+1 I would like to see some RHEL support as well.

@gamefiend

+1, yes please.

@vannenc

+1, for CentOS/RedHat

@bflad

That is awesome news.

@jefferai

Is there any information about where this plugin API is being designed? I don't see any relevant branches in the Github repository. I'm very interested in the possibility of a ZoL plugin as an alternative to btrfs and thinly-provisioned device-mapper, but if a btrfs plugin is already in development, it would be nice to be able to see that code to see what it would look like to make a ZoL version.

@pungoyal

+1 for Red Hat support

@leifwalsh

+1 centos 6, and 5 if you can get it

@goldmann

A blog post describing the details about RHEL/Fedora support for Docker: http://community.redhat.com/adventures-in-dockerland/

@sciurus

Now that

  • Docker 0.7 is released and supports devicemapper thin provisioning as an alternative to aufs
  • Docker has been packaged in Fedora and EPEL

I think this issue can be closed.

@goldmann

It's packaged, but not pushed to the repos yet. Please hold on, we'll be there soon!

@blalor

Will Docker 0.7 work on CentOS 6? I think that's still on kernel 2.6, but the Docker docks say 3.8 (?) is required.

@NuxRo

It works nicely:
yum --enablerepo=epel-testing install docker-io libcgroup
service cgconfig start
service docker start

@blalor
@blalor

Er, not quite. The docker-io service in epel-testing starts with -b none, so networking isn't available. Attempting to start docker without that flag causes it to fail.

[root@vagrant-centos63 tmp]# /usr/bin/docker -D -r=false -d
2013/11/26 19:25:07 WARNING: You are running linux kernel version 2.6.32-279.19.1.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.
[/var/lib/docker|f4b03b56] +job initapi()
[/var/lib/docker|f4b03b56.initapi()] Creating server
[debug] driver.go:84 Error loading driver aufs: AUFS was not found in /proc/filesystems
[debug] deviceset.go:475 Generated prefix: docker-253:0-404404
[debug] deviceset.go:478 Checking for existence of the pool 'docker-253:0-404404-pool'
[debug] deviceset.go:237 loadMetadata()
[debug] deviceset.go:242 loadMetadata END
[debug] runtime.go:642 Using graph driver devicemapper
[debug] network.go:150 Creating bridge docker0 with network 172.17.42.1/16
[/var/lib/docker|f4b03b56] -job initapi() = ERR (Error creating bridge: operation not supported)
2013/11/26 19:25:07 initapi: Error creating bridge: operation not supported
@NuxRo

Right, so you either need to create a bridge (docker0) by yourself and specify it in /etc/sysconfig/docker or go for a newer kernel.

Kernel-lt from Elrepo works fine at a first glance.

@NuxRo

Until docker-io makes a comeback in epel-testing it can be downloaded from http://koji.fedoraproject.org/koji/packageinfo?packageID=17053

@blalor

I'm working on a sample Vagrant box and bootstrapping script for CentOS. https://github.com/blalor/vagrant-centos64-docker It's not working yet, but there has been some good discussion on docker-dev today. You don't really need an RPM as you can just grab the docker binary. My Vagrant config still doesn't work (lxc incompatibility?) but I hope to get back to it later tonight to get it working.

@bflad

Just to follow up with this thread, the bridging and networking on CentOS 6 should be fixed along with the libcgroup/cgconfig fixes in docker-io packages as of last few days. According to Red Hat Bugzilla 1000662 and Fedora build system, the latest docker-io package (docker-io-0.7.0-14) is being pushed to EPEL 6 stable right now. Fedora build system is showing FC19/FC20 being pushed to updates stable repositories shortly as well.

Great work everyone!

@blalor

Great news!! Last I looked the docker-io package didn't set up the docker0 bridge. Does it now do that, or is that an additional step required to get Docker containers to have network access?

@bflad

All handled without effort with latest package, at least from what I can tell. :)

[root@docker-centos-6 ~]# rpm -ihv http://kojipkgs.fedoraproject.org//packages/docker-io/0.7.0/14.el6/x86_64/docker-io-0.7.0-14.el6.x86_64.rpm
Retrieving http://kojipkgs.fedoraproject.org//packages/docker-io/0.7.0/14.el6/x86_64/docker-io-0.7.0-14.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:docker-io              ########################################### [100%]
[root@docker-centos-6 ~]# cat /etc/sysconfig/docker
other_args=""
[root@docker-centos-6 ~]# service docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:                                     [  OK  ]
[root@docker-centos-6 ~]# ps aux | grep docker
root      5111  1.0  1.2 542220 12416 pts/0    Sl   03:21   0:00 /usr/bin/docker -d
[root@docker-centos-6 ~]# docker run -d -p 9999:9999 busybox /bin/nc -l -l -p 9999
Unable to find image 'busybox' (tag: latest) locally
Pulling repository busybox
e9aa60c60128: Download complete
661e7e01438e581b0acce27ea15856b824461cc64914e46b8d374e954013188b
[root@docker-centos-6 ~]# netstat -ntlp | grep 9999
tcp        0      0 :::9999                     :::*                        LISTEN      5111/docker
[root@docker-centos-6 ~]# telnet ::1 9999
Trying ::1...
Connected to ::1.
[root@docker-centos-6 ~]# brctl show
bridge name bridge id   STP enabled interfaces
docker0   8000.000000000000 no
@goldmann

@blalor It's fixed in the latest update.

All--

From now on please report all issues regarding docker-io EPEL package in the Red Hat Bugzilla. Thanks!

I'll update the docs with instruction on how to install Docker on CentOS/RHEL.

I guess we can close this issue now.

@jamtur01
Collaborator

Let's close it! :) Thanks @goldmann!

@jamtur01 jamtur01 closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.