Gentoo #313
Comments
|
Thanks for making this for me. Been so flat out over the last few days. |
|
My own simple first attempt: EAPI=4
DESCRIPTION="Docker complements LXC with a high-level API which operates at the process level. It runs unix processes with strong guarantees of isolation and repeatability across servers."
HOMEPAGE="http://www.docker.io/"
SRC_URI="/~https://github.com/dotcloud/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz"
LICENSE="Apache-2.0"
SLOT="0"
KEYWORDS="~amd64"
IUSE=""
DEPEND="
dev-lang/go
"
RDEPEND="
app-emulation/lxc
app-arch/libarchive
net-misc/curl
"
src_install() {
dobin bin/docker
} |
|
I guess it would also be helpful to mention that I called this "app-emulation/docker" and put that in docker-0.1.1.ebuild (to grab from the most recent "release" tag to avoid the annoyance of a live ebuild). |
|
I'm also thinking that dobin might be better as dosbin, since docker does have to be run as root. I'd definitely love some outside opinions. |
|
I've also added the following to the end of the ebuild (referencing issue #219), since this is probably the first issue Gentoo users will run into (even before a misconfigured kernel for LXC): pkg_postinst() {
ewarn "Docker currently assumes a network bridge named lxcbr0 exists and is usable"
ewarn "see also /~https://github.com/dotcloud/docker/issues/219"
}The best temporary solution I can see for the ebuild to do would be to create something similar to the lxcbr0 from Ubuntu (and if named differently, which is probably a good idea, perform the tiny patch necessary to network.go -- something like dockerbr0 would be more obvious). The real solution, of course, is the actual resolution of #219, especially since reliably creating said bridge at install-time would pose somewhat of a challenge (from what I know). |
|
As a side note, since the final resolution to the bridge issue will either be #221 or will be similar to it, we will need to add |
|
Sorry for waxing slightly spammy in comment volume here; I am very excited about getting this to work, and do enjoy practice making ebuilds since I have so few legitimate opportunities to do so. Here is an updated ebuild that can be either docker-0.1.1 or docker-9999 (yes, finally a proper live ebuild): EAPI=4
DESCRIPTION="Docker complements LXC with a high-level API which operates at the process level. It runs unix processes with strong guarantees of isolation and repeatability across servers."
HOMEPAGE="http://www.docker.io/"
if [[ ${PV} == *9999 ]]; then
EGIT_REPO_URI="git://github.com/dotcloud/docker.git"
inherit git-2
SRC_URI=""
KEYWORDS=""
else
SRC_URI="/~https://github.com/dotcloud/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz"
KEYWORDS="~amd64"
fi
LICENSE="Apache-2.0"
SLOT="0"
IUSE=""
DEPEND="
dev-lang/go
"
RDEPEND="
app-arch/libarchive
app-emulation/lxc
net-misc/bridge-utils
net-misc/curl
sys-apps/iproute2
"
src_install() {
dobin bin/docker
dodoc README.md
[[ ${PV} == *9999 ]] && dodoc CONTRIBUTING.md
}
pkg_postinst() {
ewarn "Docker currently assumes a network bridge named lxcbr0 exists and is usable."
ewarn "See /~https://github.com/dotcloud/docker/issues/219 for more details."
}I have also included here the runtime dependencies of |
|
We just barely got a v0.1.2 tag, but since it now uses git directly in the Makefile (to include GIT_COMMIT in the build for nice versioning information), I've updated the ebuild to just always use the git-2 eclass instead of only doing so for live ebuilds: EAPI=4
DESCRIPTION="Docker complements LXC with a high-level API which operates at the process level. It runs unix processes with strong guarantees of isolation and repeatability across servers."
HOMEPAGE="http://www.docker.io/"
SRC_URI=""
EGIT_REPO_URI="git://github.com/dotcloud/docker.git"
if [[ ${PV} == *9999 ]]; then
KEYWORDS=""
else
EGIT_COMMIT="v${PV}"
KEYWORDS="~amd64"
fi
inherit git-2
LICENSE="Apache-2.0"
SLOT="0"
IUSE=""
DEPEND="
dev-lang/go
"
RDEPEND="
app-arch/libarchive
app-emulation/lxc
net-misc/bridge-utils
net-misc/curl
sys-apps/iproute2
"
src_install() {
dobin bin/docker
dodoc README.md
[[ ${PV} == *9999 ]] && dodoc CONTRIBUTING.md
}
pkg_postinst() {
ewarn "Docker currently assumes a network bridge named lxcbr0 exists and is usable."
ewarn "See /~https://github.com/dotcloud/docker/issues/219 for more details."
}Should still be saved as either |
|
I've created a public gentoo-overlay repo for me to do further development on this in so that it will be publicly accessible and simpler for others to see, use, and contribute to. /~https://github.com/tianon/gentoo-overlay/tree/master/app-emulation/docker |
|
I finally created lxcbr0 manually to test further, and now we run into a "no such device" error in docker.go on line 40. This is one issue with just bubbling errors up and logging them at the top level. :) Full output: And again with debugging enabled, in case that helps: |
|
I should also mention that I am proficient in Go and happy to debug this with some help, but I just don't know enough about LXC or Docker at this point to go much further on my own. |
|
Hi Tianon, this "no such device" is because you don't have the aufs module On Wed, Apr 3, 2013 at 10:00 PM, Tianon Gravi notifications@github.comwrote:
|
|
Ah brilliant, thanks. Sorry, I should've thought to search the issues here. I'll play around with that and see about adding a check for that in the ebuild, too (I know it can be done, just haven't done it myself before). |
|
No worries. You hit 2 completely unrelated errors in a row, and they On Wed, Apr 3, 2013 at 10:04 PM, Tianon Gravi notifications@github.comwrote:
|
|
Indeed, very fun. :) Adding aufs to the ebuild turns out to be much easier than I was thinking. I thought it was a built-in kernel FS, but it's in a separate package, so I just need to add sys-fs/aufs3 to RDEPEND. The nasty part is that the aufs ebuild requires patching the kernel, so maybe Gentoo won't be one of the first "supported" distros outside of Ubuntu - we'll just make sure that for the experienced Gentoo user, it'll at least be possible. :) It's really a choice between the aufs3 ebuild with a patch to the kernel, or using the aufs-sources directly, which are basically gentoo-sources, but including the aufs code. We'll see what I run into next after getting aufs installed and working. |
|
Now we've made progress. Kernel recompiled and rebooted, aufs successfully loaded. After running Then it hangs for a short while (which I'm assuming is some initial setup, since the hang here didn't happen on subsequent runs), then I got: So docker actually created and ran my container! Then we hang until I press a key of some kind and we get: Obviously this is because the process is dead, but for some reason our attachment didn't know it. Maybe I've misunderstood either -i or -t? |
|
Nice! Did you run the first "docker run" on an virgin docker install? If so, the On Wed, Apr 3, 2013 at 10:50 PM, Tianon Gravi notifications@github.comwrote:
|
|
On Wed, Apr 3, 2013 at 10:50 PM, Tianon Gravi notifications@github.comwrote:
This is a bug which was introduced in the last 24 hours... We are currently |
|
I'm not sure what the delay was, since I had already pulled the busybox image, but it's certainly cool to be this far. I'm currently waiting for the ubuntu base image to download so I can play with that, too. :) So overall, Gentoo appears to be just fine as a platform, once we get the bridge figured out more nicely and now that we've got the dependencies nailed down correctly. 👍 |
|
Next step: publish a standard guest Gentoo image, so we non-gentoo users On Wed, Apr 3, 2013 at 10:58 PM, Tianon Gravi notifications@github.comwrote:
|
|
More output from the base image: With an active, working bash terminal inside the image. :) Having a Gentoo image would indeed be very nice. Not entirely sure how to go about creating such a thing, but I might look into it later (probably looking at that nice script that generates the busybox image to help me figure out what I'm doing). |
|
You can create a new image from a tarball with 'docker import'. For example, if "rootfs" containers a full root filesystem: 'tar -C On Wed, Apr 3, 2013 at 11:04 PM, Tianon Gravi notifications@github.comwrote:
|
|
Hmm, that base image doesn't have internet, so I'm pretty much positive my lxcbr0 is not setup correctly, which is odd since I followed the same steps in the pull request that's trying to normalize all that. Here's what I did: Learning about how docker import works, we might be able to use a stage3 directly. That would be magical and mind-blowing. I'm definitely going to have to play with that more. |
|
Fyi, those steps were specifically from /~https://github.com/dotcloud/docker/pull/221/files#L3R457 (the CreateIface function). If they aren't right or aren't sufficient, then that pull request definitely needs more loving. :) |
|
Just to double-check, can you confirm ip routing to the outside is broken, On Wednesday, April 3, 2013, Tianon Gravi wrote:
|
|
I always verify connectivity with a ping to 8.8.8.8 before I ever try google.com. :P |
|
I assumed so - but had to ask! :) On Wednesday, April 3, 2013, Tianon Gravi wrote:
|
|
Understand completely. :) Also, |
|
To further muddy the waters of this conversational thread, here's some output from my initial attempt at pushing the Gentoo stage3 into a docker image: And for completeness, the full steps performed to create said image: wget -c 'http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/default/20130321/stage3-amd64-20130321.tar.bz2'
mkdir rootfs
# basically following the Gentoo Handbook from here to get our initial chroot environment setup (which should be sufficient for a docker image, too, in theory)
(cd rootfs && sudo tar xvjpf ../stage3-amd64-20130321.tar.bz2)
sudo vim rootfs/etc/portage/make.conf # just to verify CFLAGS/CXXFLAGS and add GENTOO_MIRRORS and SYNC as per the handbook -- not strictly necessary just to get a working chroot environment
sudo vim rootfs/etc/resolv.conf # to add nameservers -- also not strictly necessary for a "working" chroot environment
sudo tar -C rootfs -c . | sudo docker import - tianon/gentooI suppose I really ought to go look at that example script and make sure I'm not missing something important that makes a docker image different from the stage3 I've created. |
|
Could it be the fact that the stage3 dev is not empty, and thus wouldn't like being mounted on top of without force? Any other directories that might have similar issues? Are dev, proc, and sys mounted by docker/lxc directly? |
|
Ah, interesting article, thanks. lxc warns me for not having it as well, but like I said, docker still has no issues with running containers. It looks like that's probably more for running containers as a non-root host user and still having root inside the container, where docker just runs everything as root on the host. I'll definitely keep my eye on this, and probably add some more einfo text to my docker ebuild about it. Thanks very much for the information about how far you had to go to get it enabled. |
|
With the latest version (baacae8), I'm getting the following error when I try to start up the daemon: I would guess that this is related to the new kernel version checking code, but don't know for sure. In case it helps, the output of |
|
Yes, I think your diagnostic is correct. I'll look into it. On Sun, Apr 21, 2013 at 2:32 PM, Tianon Gravi notifications@github.comwrote:
|
|
More exactly, I'd think it's on line 437 of utils.go, since my "specific" version is literally the string 'gentoo'. |
|
I think a reasonable fix would probably be to convert that "Specific" struct field into a string. If this is an acceptable solution and if it were helpful for me to do so, I'd be happy to submit a pull request for it (including fixing the necessary tests and possibly adding one or two more for testing some non-integer specific values). |
|
That sounds reasonable to me. A few notes:
Thanks for offering a PR. I will gladly accept it :) On Sun, Apr 21, 2013 at 3:47 PM, Tianon Gravi notifications@github.comwrote:
|
|
Thanks for the pointers. I looked to Wikipedia to verify my memory on the subject of that fourth bit, and it has the following to say most recently about it (Linux kernel#Version numbering):
It was originally used as a security update, bugfix, and patch bump number, but Torvalds deprecated that (as of 3.0) in favor of using the third digit for that and using the suffix for any build-specific information (in this case, |
|
Oh, and as for official verbiage, "suffix" is the best I can find/tell, so it would seem that Flavor is as good a name as any, since that's basically what it describes. |
|
Sounds good to me. Let's drop it from the comparison then. Thanks! On Sun, Apr 21, 2013 at 4:48 PM, Tianon Gravi notifications@github.comwrote:
|
|
Onward and upward. As you can see, pull request submitted; now we have a new error: (This is preceded by the contents of the output of the Here's some (hopefully) relevant mount output: |
|
Quick update on aufs3 + CONFIG_USER_NS on gentoo, it's now fixed in sys-kernel/aufs-sources-3.8.8-r1. |
|
That's definitely good news. I also want to report that the cgroup fix yesterday solved my issue, and I'm successfully starting the docker daemon again and running images. I'm in the process of fixing the tianon/gentoo image so I can push up a new (fixed) image that includes /bin/ip, and will update the "public docker images" wiki page again when I have the new version working and pushed up. |
|
The tianon/gentoo image is fixed and uploaded, and the public docker images page is updated to reflect that and the remaining caveats of the image (namely, that it does not include a copy of the portage tree, since that can get pretty large and quickly goes stale). |
|
Oh, and I also updated the ebuild in my overlay to copy a few of the files from the contrib directory into /usr/share/, as is the convention with several other packages (mostly just the stuff that is currently widely useful directly or as a reference, or will be in the future such as the vagrant directory). |
|
I felt like having a little more fun with ebuilds this evening, so I created a companion ebuild for app-emulation/docker-bin that installs the official docker-v0.1.8.tgz binary. The main benefit for this that I can see (beyond the obvious bug narrowing down we get from an official "gold" binary) is that it doesn't require dev-lang/go to be installed to build it, which could be a plus on a micro server without a lot of resources or space (which does beg the question of why one would want docker on it, but I digress). I think it's also worth mentioning that both of these ebuilds are 64bit only, as is docker itself (for the time being, as noted in #136, which decision I fully support and applaud for the focus it helps provide in the short term). |
|
In reference to the "official package name" discussion on #406, on Gentoo we only have a conflict with just calling the package "docker" if there's another package in the same category with said name (since the package name is really "app-emulation/docker"). Would you guys prefer it be "app-emulation/lxc-docker" to match the other platforms, or keep the simple "docker" name because we can? :) |
|
The similarly named package is "x11-plugins/docker", which does cause a little confusion, especially if one doesn't specify the category when installing. I think my vote is on matching the other platforms, both for consistency and for clarity. |
|
Yeah +1 for matching other platforms. Thanks! On Wed, Apr 24, 2013 at 7:16 AM, Tianon Gravi notifications@github.com
|
|
So on other platforms, the binary is being installed as "docker" (as it is generated in the code). Is the init script also "docker" to match the binary, or is it "lxc-docker" to match the package name? |
|
I decided to answer my own question since I realized that I have "ubuntu" (inside Docker, of course). I had to go add the universe repo to the ubuntu image (as well as the PPA), but after getting it installed, found that the upstart script is indeed called "docker", and so Gentoo's will stay that way as well. 👍 |
|
As it seems that auto-referencing this issue from #490 a 2nd time didn't work, here's a copy of my last message: Now, that most distributions make use of systemd, what about simply providing a corresponding sysctl.d file to enable IP forwarding? /usr/lib/sysctl.d/docker-ip-forwarding.conf Then the few remaining distributions which don't provide support for systemd (yet) would only have to actually take care about dealing with this. Regarding issue #313: The current Gentoo policy for installing systemd files is: they're always installed, independent from |
|
Hey guys, I'm going over old issues to keep the list under control. Since I believe there is an ebuild, should we perhaps close this? If there are still specific problems which haven't been fixed in the last 4 months, at this point I suggest creating a fresh actionable issue for each. Closing tentatively, I will gladly re-open if I'm missing something. |
|
Sounds good to me; thanks @shykes. |
|
Just as a reference for those following along at home (or work!), I've moved the lxc-docker ebuilds out of my personal overlay and into a dedicated docker-overlay: /~https://github.com/tianon/docker-overlay |
|
RIP |
…ch_but_it_was_busted [19.03 backport] use GO_VERSION and pin to debian stretch
A nice ebuild/support for Gentoo would be a great feature. Gentoo users are usually willing to try new things, especially fun ones like Docker.
@lucractius was told to create a ticket, but never did (that I could find), so here we have it. :)
The text was updated successfully, but these errors were encountered: