I was recently asked if there was a docker option available to set the timezone in a container. There isn't one, and I started looking into whether it would be a good feature-add. I found several github issues discussing how to best set it. There were recommendations of bind-mounting /etc/localtime, or setting an environment variable (though no one went into much detail on that one). I did a little googling this morning, and came across a new environment variable: TZ.
TZ is available on all POSIX-compliant systems. You can pass in a timezone using Olson Format, e.g. America/Chicago. Read more about TZ here: https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.
To find the timezone, Ubuntu, and RHEL-based systems all seem to sym-link /etc/localtime to a timezone file. If someone has just overwritten it on your system, you'll have to modify accordingly.
On my laptop:
> readlink /etc/localtime
../usr/share/zoneinfo/America/Chicago
Docker has a flag, -e, to pass in environment variables via the CLI.
-----------------
Using the two together, all you really need is:
`docker run -it --rm -e "TZ=$(readlink /etc/localtime | cut -d '/' -f5,6 )" centos:7`
You can run it once without specifying the timezone:
> docker run -it --rm centos:7 date +%Z
UTC
And again with it to check:
> docker run -it --rm -e "TZ=$(readlink /etc/localtime | cut -d '/' -f5,6)" centos:7 date +%Z
CDT
You can also choose a specific timezone:
> docker run -it --rm -e "TZ=Asia/Tehran" centos:7 date +%Z
IRDT
Wednesday, August 31, 2016
Wednesday, June 15, 2016
running x86 containers on your ppc64le system
My last post was about running other architectures' containers on your laptop. This one's about running x86_64/amd64 containers on your ppc64le system!
If you didn't read the previous post, and want to know how this works, here is is: http://christycodes.blogspot.com/2016/06/running-cross-arch-container-images-on.html
Here's how you can do this (informational items in gray):
~> uname -m
ppc64le
1. Get the qemu emulator binaries:
~> apt-get download qemu-user-static
~> ls qemu-user-static_1%3a2.5+dfsg-5ubuntu10.1_ppc64el.deb
qemu-user-static_1%3a2.5+dfsg-5ubuntu10.1_ppc64el.deb
~> sudo dpkg --force-all -i qemu-user-static_1%3a2.5+dfsg-5ubuntu10.1_ppc64el.deb
Note: I intentionally didn't use apt-get install for qemu-user-static because I didn't want the binfmt-utils package.
2. Get/run the container that registers the binfmt hooks:
~> mkdir multiarch && cd multiarch && git clone https://github.com/clnperez/qemu-user-static.git && cd qemu-user-static/register
~> docker build -t multiarch/qemu-user-static:register .
~> ls /proc/sys/fs/binfmt_misc/
register status
~> docker run --rm --privileged multiarch/qemu-user-static:register
~> ls /proc/sys/fs/binfmt_misc/
aarch64 alpha arm armeb i386 i486 m68k mips mips64 mips64el mipsel mipsn32 mipsn32el register s390x sh4 sh4eb sparc status
3. Run your x86 image:
> docker run --rm -v /usr/bin/qemu-x86_64-static:/usr/bin/qemu-x86_64-static busybox uname -a
Linux 77ce603ac0f1 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:35 UTC 2016 x86_64 GNU/Linux
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
Note: That TCG error means that there's a missing CPU feature, but I'm not entirely sure that TCG doesn't support vmx, so I'm going to ask around.
If you didn't read the previous post, and want to know how this works, here is is: http://christycodes.blogspot.com/2016/06/running-cross-arch-container-images-on.html
Here's how you can do this (informational items in gray):
~> uname -m
ppc64le
1. Get the qemu emulator binaries:
~> apt-get download qemu-user-static
~> ls qemu-user-static_1%3a2.5+dfsg-5ubuntu10.1_ppc64el.deb
qemu-user-static_1%3a2.5+dfsg-5ubuntu10.1_ppc64el.deb
~> sudo dpkg --force-all -i qemu-user-static_1%3a2.5+dfsg-5ubuntu10.1_ppc64el.deb
Note: I intentionally didn't use apt-get install for qemu-user-static because I didn't want the binfmt-utils package.
2. Get/run the container that registers the binfmt hooks:
~> mkdir multiarch && cd multiarch && git clone https://github.com/clnperez/qemu-user-static.git && cd qemu-user-static/register
~> docker build -t multiarch/qemu-user-static:register .
~> ls /proc/sys/fs/binfmt_misc/
register status
~> docker run --rm --privileged multiarch/qemu-user-static:register
~> ls /proc/sys/fs/binfmt_misc/
aarch64 alpha arm armeb i386 i486 m68k mips mips64 mips64el mipsel mipsn32 mipsn32el register s390x sh4 sh4eb sparc status
3. Run your x86 image:
> docker run --rm -v /usr/bin/qemu-x86_64-static:/usr/bin/qemu-x86_64-static busybox uname -a
Linux 77ce603ac0f1 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:35 UTC 2016 x86_64 GNU/Linux
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
Note: That TCG error means that there's a missing CPU feature, but I'm not entirely sure that TCG doesn't support vmx, so I'm going to ask around.
Running cross-arch container images on your linux laptop
With the introduction of Docker for Mac, I ran across an exciting blog post: http://blog.hypriot.com/post/first-touch-down-with-docker-for-mac. I don't use a Mac for development, but what made that blog post interesting to me was the "Easter Egg" bit. It was titled, "There is another big ARM surprise," which is pretty sweet (so hopefully you've read that by now).
But what about other architectures? And what about not just doing this in a Mac? Well, get your ribboned baskets ready, because that Easter Egg has led me to a giant Easter Egg minefield of awesome. There are some folks over at Scaleway working on a multiarch project, and they've put together two key things:
In Linux, there's a binary that allows you to run ELF binaries that weren't compiled for the architecture you are running on. It's called binfmt_misc, and you can read more about it here: https://www.kernel.org/doc/Documentation/binfmt_misc.txt.That binary doesn't actually run the program. It just provides the mechanism to make sure the right interpreter does, based on some bits embedded in the program itself. The binfmt_misc binary checks the magic bits, then cross-references with what it finds in /proc/sys/fs/binfmt_misc/ for what to do.
That's where #1 comes in. binfmt_misc comes shipped with most Linux distros, but it can't do the job alone. It needs an interpreter. And what better interepreter than qemu? The multiarch project includes over a dozen compiled static qemu binaries! There's more than just the ARM qemu binary in there, so whatever architecture you want to run, I bet it's in their list.
But you can't just plop the emulator into your system and start running ARM or POWER containers. You've got to let binfmt_misc know what binaries should do what. You've got to set up those magic numbers, and also have them point to the right place. That's where #2 is fantastic. Not only are all the strings that binfmt_misc needs already assembled, the Scaleway folks created a docker container that will add them all to your host! If they hadn't you'd have to put together strings like
and then get them in the right place in your fs. Instead, you just run:
and you're set up!
You can check that these were added by:
$ ls /proc/sys/fs/binfmt_misc/
aarch64 arm kshcomp mips mips64el mipsn32 ppc ppc64le s390x sh4eb status alpha armeb m68k mips64 mipsel mipsn32el ppc64 register sh4 sparc
(Note: You do also have to have binfmt_misc mounted on your system, but I'm leaving that step out because on my F23 workstation it was mounted by default.)
All that's left is running the container. But the container needs access to the emulator, so you can just bind-mount it at runtime (e.g. with docker's -v).
So now, for those of you who stayed with me, thanks. For everyone else, it's deer time.
Oh hai! Let's go:
My example was with ppc64le, but you can download one of the other qemu binaries in the first step, depending on intended arch of the container you want run.
But what about other architectures? And what about not just doing this in a Mac? Well, get your ribboned baskets ready, because that Easter Egg has led me to a giant Easter Egg minefield of awesome. There are some folks over at Scaleway working on a multiarch project, and they've put together two key things:
- All the Easter Eggs: [scroll to Downloads] https://github.com/multiarch/qemu-user-static/releases
- The prep your Easter basket needs to use them: https://hub.docker.com/r/multiarch/qemu-user-static
In Linux, there's a binary that allows you to run ELF binaries that weren't compiled for the architecture you are running on. It's called binfmt_misc, and you can read more about it here: https://www.kernel.org/doc/Documentation/binfmt_misc.txt.That binary doesn't actually run the program. It just provides the mechanism to make sure the right interpreter does, based on some bits embedded in the program itself. The binfmt_misc binary checks the magic bits, then cross-references with what it finds in /proc/sys/fs/binfmt_misc/ for what to do.
That's where #1 comes in. binfmt_misc comes shipped with most Linux distros, but it can't do the job alone. It needs an interpreter. And what better interepreter than qemu? The multiarch project includes over a dozen compiled static qemu binaries! There's more than just the ARM qemu binary in there, so whatever architecture you want to run, I bet it's in their list.
But you can't just plop the emulator into your system and start running ARM or POWER containers. You've got to let binfmt_misc know what binaries should do what. You've got to set up those magic numbers, and also have them point to the right place. That's where #2 is fantastic. Not only are all the strings that binfmt_misc needs already assembled, the Scaleway folks created a docker container that will add them all to your host! If they hadn't you'd have to put together strings like
:ppc64le:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00:'${QEMU_BIN_DIR}'/qemu-ppc64le-static:and then get them in the right place in your fs. Instead, you just run:
$ docker run --rm --privileged multiarch/qemu-user-static:register
and you're set up!
You can check that these were added by:
$ ls /proc/sys/fs/binfmt_misc/
aarch64 arm kshcomp mips mips64el mipsn32 ppc ppc64le s390x sh4eb status alpha armeb m68k mips64 mipsel mipsn32el ppc64 register sh4 sparc
(Note: You do also have to have binfmt_misc mounted on your system, but I'm leaving that step out because on my F23 workstation it was mounted by default.)
All that's left is running the container. But the container needs access to the emulator, so you can just bind-mount it at runtime (e.g. with docker's -v).
So now, for those of you who stayed with me, thanks. For everyone else, it's deer time.
- Download https://github.com/multiarch/qemu-user-static/releases/download/v2.8.1/x86_64_qemu-ppc64le-static.tar.gz -o x86_64_qemu-ppc64le-static.tar.gz
- $
docker run --rm --privileged multiarch/qemu-user-static:register $ docker run -it --rm -v /home/yournamehere/Downloads/qemu-ppc64le-static:/usr/bin/qemu-ppc64le-static ppc64le/busybox:latest uname -a
My example was with ppc64le, but you can download one of the other qemu binaries in the first step, depending on intended arch of the container you want run.
Monday, April 4, 2016
git log: Print more info, including merged patches
Put this in your .bashrc
git(){
if [[ $@ == "log" ]]; then
command git log --pretty=fuller --simplify-merges --full-history
else
command git "$@"
fi
}
Thanks for the tip, http://superuser.com/a/105389
Thursday, March 3, 2016
Copying with tmux and vim on Fedora 23
I use tmux and vim on Fedora 23. When I have vertically split windows, selecting with my mouse cursor selects across multiple open files. Today I finally got unlazy and googled around enough to figure out how to get text into my system's clipboard (since vim uses it's own paste buffer) from vim.
I used
Conner's answer here: http://stackoverflow.com/questions/11489428/how-to-make-vim-paste-from-and-copy-to-systems-clipboard and Ignacio Vazquez-Abrams's answer here:
http://superuser.com/questions/194747/how-to-install-vim-with-clipboard-support-on-fedora
to get copy/paste working for me.
If you're new to vim, use :paste before pasting in code-blocks to preserve formatting.
I used
Conner's answer here: http://stackoverflow.com/questions/11489428/how-to-make-vim-paste-from-and-copy-to-systems-clipboard and Ignacio Vazquez-Abrams's answer here:
http://superuser.com/questions/194747/how-to-install-vim-with-clipboard-support-on-fedora
to get copy/paste working for me.
- install gvim
- create an alias in my .bashrc file so I don't have to type 'gvim -v' instead of 'vi'
- To select:
- position your cursor at the beginning of the text block you want to copy
- shift+v ('V')
- arrow down
- "yank" the text using "+y (keydown shift ' and +, then keyup shift, then y)
- Paste into a different program (like gedit, which I use as a scratch-pad) using your mouse wheel or ctrl+v
If you're new to vim, use :paste before pasting in code-blocks to preserve formatting.
Thursday, January 21, 2016
My Vagrant How-To (with libvirt)
I am super late the the Vagrant party. "All you have to do is vagrant up!" is all I hear from developers everywhere. But when I tried it, that was not my experience.
A lot of my life over the past several years has revolved around Linux and libvirt. I even did some backend work for a virtualization management platform called Kimchi. But since I was coming from the land of, "Here's your image, and here's your VM," I over-complicated it. "Where is the image I just downloaded?" "Doesn't my Vagrantfile need to be in the same place as that image?" The answers: "Don't worry about it," and "No."
So here's what I think is a pretty good explanation for people who are used to something like virt-manager but want to use Vagrant.
Set up a directory to house your projects. You could source-control it, too. Then make subdirectories for each project:
$ mkdir vagrantfiles && cd vagrantfiles
$ mkdir someproject && cd someproject
This is before you've added any boxes. The directories will hold your `Vagrantfile`s – not your boxes. The base boxes (or .img files) live in ~/.vagrant.d/boxes, and are base images. When you set up a project, you'll be building on top of that base image. This allows sharing of one base image across multiple projects. So, pick a base you'd like to use a lot, and you'll save space on your hardrive.
Decide which box you want. You can look at available boxes from hashicorp here: https://atlas.hashicorp.com/boxes/search. Clicking on a box will show you more useful info, like the init command to use to get that box.
I want to use Fedora and libvirt (see Vagrant with Libvirt (on Fedora)), so I'm looking at https://atlas.hashicorp.com/fedora/boxes/23-cloud-base. Let's init our project:
$ vagrant init fedora/23-cloud-base
If this is the first time you've used this box, it will download the base image. When it completes, you'll see a Vagrantfile in your directory. If you want to do additional config, change your Vagrantfile first. The default one will get you a working VM with host networking, so that's good enough for me.
Now, up your box:
$ vagrant up --provider libvirt # watch the config & start
$ sudo virsh list –all # see that your box is now running
$ vagrant ssh # access your machine
For more, definitely read the Vagrant docs: https://www.vagrantup.com/docs/getting-started
$ dnf install vagrant-libvirt
The default memory is 512M, which isn't going to cut it for my purposes. so I've gone back and updated my VM. In the future, I'll remember to add the following to my Vagrantfile *before* I 'vagrant up.'
config.vm.provider :libvirt do |libvirt|
libvirt.memory = 2048
end
A lot of my life over the past several years has revolved around Linux and libvirt. I even did some backend work for a virtualization management platform called Kimchi. But since I was coming from the land of, "Here's your image, and here's your VM," I over-complicated it. "Where is the image I just downloaded?" "Doesn't my Vagrantfile need to be in the same place as that image?" The answers: "Don't worry about it," and "No."
So here's what I think is a pretty good explanation for people who are used to something like virt-manager but want to use Vagrant.
Intro: Projects, Vagrantfiles, & Boxes
Set up a directory to house your projects. You could source-control it, too. Then make subdirectories for each project:
$ mkdir vagrantfiles && cd vagrantfiles
$ mkdir someproject && cd someproject
This is before you've added any boxes. The directories will hold your `Vagrantfile`s – not your boxes. The base boxes (or .img files) live in ~/.vagrant.d/boxes, and are base images. When you set up a project, you'll be building on top of that base image. This allows sharing of one base image across multiple projects. So, pick a base you'd like to use a lot, and you'll save space on your hardrive.
Decide which box you want. You can look at available boxes from hashicorp here: https://atlas.hashicorp.com/boxes/search. Clicking on a box will show you more useful info, like the init command to use to get that box.
I want to use Fedora and libvirt (see Vagrant with Libvirt (on Fedora)), so I'm looking at https://atlas.hashicorp.com/fedora/boxes/23-cloud-base. Let's init our project:
$ vagrant init fedora/23-cloud-base
If this is the first time you've used this box, it will download the base image. When it completes, you'll see a Vagrantfile in your directory. If you want to do additional config, change your Vagrantfile first. The default one will get you a working VM with host networking, so that's good enough for me.
Now, up your box:
$ vagrant up --provider libvirt # watch the config & start
$ sudo virsh list –all # see that your box is now running
$ vagrant ssh # access your machine
For more, definitely read the Vagrant docs: https://www.vagrantup.com/docs/getting-started
Vagrant with Libvirt (on Fedora)
Installing the Plugin
There is a project to use libvirt instead of the default (Virtualbox) with Vagrant: https://github.com/pradels/vagrant-libvirt. The project instructions say to use the vagrant command to install the libvirt plugin. However, for Fedora at least, you should use dnf to install the plugin:$ dnf install vagrant-libvirt
Box Configuration
As opposed to the Virtualbox provider, if you want to update some VM properties (e.g. VCPUs or memory), you'll need to use virsh (read: do it outside of Vagrant).The default memory is 512M, which isn't going to cut it for my purposes. so I've gone back and updated my VM. In the future, I'll remember to add the following to my Vagrantfile *before* I 'vagrant up.'
config.vm.provider :libvirt do |libvirt|
libvirt.memory = 2048
end
Subscribe to:
Posts (Atom)