Опубликовано
Комментарии Нет

При написание Dockerfile зачастую в контейнере требуется запустить больше одного процесса, и первое, что приходит в голову, в качестве основного процесса, взять bash скрипт.

При вызове docker stop, главному процессу контейнера отправляется сигнал TERM, а после окончания таймаута ожидания – KILL.

Чтобы bash скрипт умел обрабатывать сигнал TERM и сразу останавливался, необходимо добавить в него строчку, тогда он сможет выйти из while цикла:

trap break TERM

Пример пустого контейнера c Ubuntu 16.04, без запущенных процессов:
Dockerfile

FROM ubuntu:16.04
ADD run.sh /
RUN chmod +x run.sh
CMD ["/run.sh"]

run.sh

#!/bin/bash
trap break TERM
while :
do
    sleep 1
done

Автор

Опубликовано
Комментарии Нет

Иногда возникают задачи, когда размер запускаемого образа системы имеет значение. Особенно это актуально для встраиваемых систем, где ресурсы ограничены, а от системы требуется стабильность и простота. Для сборки подобных образов существуют различные инструменты, один из них я и решил попробовать. Им стал BuildRoot

Загружаем из git и погружаемся в настройку.

git clone git://git.buildroot.net/buildroot
cd buildroot
make menuconfig

Данный пример не будет иметь какого-либо полезного практического применения.

System configuration —> System banner ( Iperf Test )

Kernel —> [ * ] Linux Kernel
Kernel —> Defconfig name ( i386 )

Target packages —> Networking application —> [ * ] iperf3

Filesystem images —> [ * ] initial RAM filesystem linked into linux kernel

make linux-menuconfig

Networking support —> [ ] Wireless

Device Drivers —> [ * ] Virtualization drivers
Device Drivers —> Virtio drivers —> [ * ] все пункты.
Device Drivers —> Network device support —> [ * ] Virtio network driver
Device Drivers —> Network device support —> [ ] Wireless LAN

Сохраняем и выходим.

make

Скомпилируется не быстро, так что можно запустить в screen и уйти за чашечкой чая.
В результате получим образ в ./output/images/bzImage, он нам и нужен.

Создаем новую виртуальную машину без диска в virt-manager
iperf_net
iperf_net

Пользователь для входа root, пароль мы оставили пустым.
После старта получаем ip

udhcpc eth0

Проверяем работу сети:
Iperf

Автор

Опубликовано
Комментарии Нет

Plan9

Plan9 – это операционная система, разнаботанная в Bell Labs ещё в 80х годах. Данная ОС построена на трех принципах:

  1. Ресурсы представлены как файлы и доступны в иерархической файловой системе.
  2. Локальные и удалённые ресурсы не различаются. Доступ осуществляется через сетевой протокол 9P
  3. У каждой группы процессов есть собственное пространство имен, составленное из файловых иерархий, предоставляющихся различными ресурсами.

Четвертая и последняя версия протокола 9P используется в qemu, для подключения папок в гостевую ось, о чем более подробно, напишу чуть позже в отдельной статье.

Запуск Plan9

kvm -cdrom plan9.iso -boot d

При загрузке выбираем пункт загрузки ( второй пункт ). При загрузке будут вопросы, можно указать чуть большее расширение 800×600×8 и видео драйвер vesa.

Plan9

Установка.

Создадим виртуальный диск формата qcow2 на 2G:

qemu-img create -f qcow2 Plan9.qcow2.img 2G

И запустим на установку, выбрав пункт 1.
qemu -hda Plan9.qcow2.img -cdrom plan9.iso -boot d

При установке потребуется ответить на ряд вопросов.

Или можно загрузить предустановленный образ

gunzip gPlan9.qcow2.img.tgz
tar xvf  gPlan9.qcow2.img.tar

И выполнить запуск:

kvm -hda gPlan9.qcow2.img -net nic -net user

Автор

Опубликовано
Комментарии Нет

В образе CoreOS все системные сервисы кастомизированы, такие как сетевой интерфейс, системные пользователи, systemd скрипты – все настраивается при загрузке образа системы, программой coreos-cloudinit, на основе “облачного” конфигурационного файла.
Конфигурационный файл добавляется в систему через транспорт для обмена файлами 9p
Подобный конфигурационный файл был применен в прошлой заметке по CoreOS, это файл user_data с ssh ключем.
Кофигурационный файл использует формат YAML, что добавляет ему читабельности в отличие от xml файлов. Для загрузки конфига в системе и его валидации существует команда coreos-cloudinit.
Проверить написанный конфиг можно так:

coreos-cloudinit -validate --from-file ИМЯ_ФАЙЛА.

Или воспользоваться online версией.

Конфигурационный файл всегда должен начинаться со строки:

#cloud-config

И может содержать следующие секции:

    coreos
    ssh_authorized_keys
    hostname
    users
    write_files
    manage_etc_hosts

Более подробно о каждой секции расскажу чуть позже, а сейчас приведу пример настройки iptables через cloud-counfig.

~ # cat config.yaml 
#cloud-config
coreos:
  units:
    - name: iptables-restore.service
      enable: true
write_files:
  - path: /var/lib/iptables/rules-save
    permissions: 0644
    owner: root:root
    content: |
      *filter
      :INPUT DROP [0:0]
      :FORWARD DROP [0:0]
      :OUTPUT ACCEPT [0:0]
      -A INPUT -i lo -j ACCEPT
      -A INPUT -i eth1 -j ACCEPT
      -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
      -A INPUT -p tcp -m multiport --dport 22,80,443 -j ACCEPT
      -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
      -A INPUT -j DROP
      COMMIT

Секция units описывает список сервисов, которыми должны быть запущены через systemd.
Секция write_files определят, какие файлы и с каким содержимым должны быть созданы в локальной системе.

Загружаем конфигурационный файл:

~ # coreos-cloudinit --from-file config.yaml 
Checking availability of "local-file"
Fetching user-data from datasource of type "local-file"
Fetching meta-data from datasource of type "local-file"
2015/07/16 07:26:16 Parsing user-data as cloud-config
Merging cloud-config from meta-data and user-data
2015/07/16 07:26:16 Writing file to "/var/lib/iptables/rules-save"
2015/07/16 07:26:16 Wrote file to "/var/lib/iptables/rules-save"
2015/07/16 07:26:16 Wrote file /var/lib/iptables/rules-save to filesystem
2015/07/16 07:26:16 Updated /etc/environment
2015/07/16 07:26:16 Enabling unit file "iptables-restore.service"
2015/07/16 07:26:16 Enabled unit "iptables-restore.service"
2015/07/16 07:26:16 Ensuring runtime unit file "etcd.service" is unmasked
2015/07/16 07:26:16 Ensuring runtime unit file "etcd2.service" is unmasked
2015/07/16 07:26:16 Ensuring runtime unit file "fleet.service" is unmasked
2015/07/16 07:26:16 Ensuring runtime unit file "locksmithd.service" is unmasked

Настройки конфигурационного файла вступят в силу при следующей загрузке системы.

Автор

Опубликовано
Комментарии Нет

hn.CoreOS

CoreOS – это не просто операционная система основанная на Linux, это open source проект для запуска Linux контейнеров, который включает в себя кроме сборки системы с Docker, но и ряд компонент для интеграции с различными проектами, например OpenStack.

Первое знакомство.

Как запустить версию CoreOS в kvm+libvirt? А очень просто:

Загружаем последний образ системы:

mkdir -p /var/lib/libvirt/images/coreos0
cd /var/lib/libvirt/images/coreos0
wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_qemu_image.img.bz2 -O- | bzcat > coreos_production_qemu_image.img

Создаем конфигурационный файл с ssh ключем и настройками сети:

mkdir -p /var/lib/libvirt/images/coreos0/configdrive/openstack/latest
touch /var/lib/libvirt/images/coreos0/configdrive/openstack/latest/user_data

В конфигурационный файл user_data подставляем свой ssh-rsa:


#cloud-config

ssh_authorized_keys: – ssh-rsa AAAAB3NzaC1yc2EAAAADAQABA…

Создаем конфигурационный файл core0.xml для libvirt:

<domain type='kvm'>
  <name>coreos0</name>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/coreos0/coreos_production_qemu_image.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <controller type='usb' index='0'>
    </controller>
    <filesystem type='mount' accessmode='squash'>
      <source dir='/var/lib/libvirt/images/coreos0/configdrive/'/>
      <target dir='config-2'/>
      <readonly/>
    </filesystem>
    <interface type='network'>
      <mac address='52:54:00:b4:2f:23'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <sound model='ich6'>
    </sound>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
    </video>
    <memballoon model='virtio'>
    </memballoon>
  </devices>
</domain>

Создаем и запускаем машину:

virsh define core0.xml
virsh start coreos0

В загрузившейся системе видно, что интерфейс eth0 получил адрес 192.168.122.194
coreos_eth0

Подключаемся по ssh:

~$ ssh core@192.168.122.194
Last login: Thu Jun 18 08:03:45 2015 from 192.168.122.1
CoreOS stable (681.1.0)
Failed Units: 1
  user-configvirtfs.service
core@localhost ~ $ docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2-dirty
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 7c8fca2-dirty
OS/Arch (server): linux/amd64
core@localhost ~ $ uname -a
Linux localhost 4.0.5 #2 SMP Wed Jun 17 07:09:22 UTC 2015 x86_64 QEMU Virtual CPU version 2.0.0 GenuineIntel GNU/Linux

Автор

← Старые Новые →