Играемся с LXC в командной строке

Если вдруг вам приходится часто и много оперировать с LXC контейнерами, есть маленький лайфхак для помощи хардкорщику в консоли. Эти маленькие помощники — алиасы qgeicez. Чтоб много не говорить, привожу строки, которые надо добавить в конфигурационный файл пользователя ~/.bashrc

Для обычного пользователя, оперирующего привелегированными контейнерами:

alias lxls='sudo lxc-ls -f'
alias lxon='sudo lxc-start -n'
alias lxoff='sudo lxc-stop -n'
alias lxat='sudo lxc-attach -n'
alias lxcp='sudo lxc-copy -s -n ubuntu-sample -N'
alias lxrm='sudo lxc-destroy -n'

Для пользователя root и обычного пользователя, оперирующего непривелегированными контейнерами:

alias lxls='lxc-ls -f'
alias lxon='lxc-start -n'
alias lxoff='lxc-stop -n'
alias lxat='lxc-attach -n'
alias lxcp='lxc-copy -s -n ubuntu-sample -N'
alias lxrm='lxc-destroy -n'

Комментарий нужен, пожалуй, только по строке с lxcp, где ожидается, что у вас ест шаблонный контейнер ubuntu-sample с базовой системой и есть техническая возможность работы overlayfs, которая делает новый создаваемый контейнер в виде delta-образа файловой системы поверх шаблонного (очень экономит время и диск). В противном случае замените команду на

lxc-copy -n ubuntu-sample -N

Как использовать

Если вы поняли, что написано выше, это уже вероятно излишне, но для полноты. После повторного входа в систему вам будут доступны хелперы-алиасы.

Создаем клон шаблонного контейнера для нужных нам задач:

lxcp task1

Запускаем:

lxon task1

Переходим в контейнер (для выхода достаточно выйти через Ctrl+D):

lxat task1

Останавливаем:

lxoff task1

Удаляем:

lxrm task1

Все обновления системы и общие для всех клонированных контейнеров правки можно делать в контейнере-шаблоне.

~ FIN ~

 

Комментариев нет »13.01.2017 09:10:17 | Ubuntu, Изобретаю | ,

Is your DNS round-robin setup really round?

round-robin

Just test!

Take this simple script and test on your own, with python 2 or 3.

Options:

usage: dns_round_robin_test.py [-h] [-c COUNT] [-d DELAY] name

positional arguments:
 name                  DNS name to test

optional arguments:
 -h, --help            show this help message and exit
 -c COUNT, --count COUNT
                       set total count of resolves
 -d DELAY, --delay DELAY
                       set delay between resolves in 1/100s of second

Sample run command:

$ ./dns_round_robin_test.py google.com -c 20

Sample output:

================ google.com ================ 20/20
 188.43.66.170 [                ||||| 25.0%] 5
 188.43.66.187 [                ||||| 25.0%] 5
 188.43.66.174 [           |||||||||| 50.0%] 10

Комментариев нет »20.12.2015 17:15:06 | English, Делаю | , , , ,

Поставить сервер непрерывной интеграции Jenkins на Ubuntu

Дано:

Ubuntu 12.04 LTS (серверная или настольная редакция).

Надо:*

Установить сервер непрерывной интеграции Jenkins.

Решение:

Всё очень просто (см. http://pkg.jenkins-ci.org/debian/):

  1. Добавляем ключ репозитория Jenkins:
    wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
  2. Добавляем сам репозиторий:
    echo "deb http://pkg.jenkins-ci.org/debian binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list
  3. Обновляем информацию о доступности пакетов программ с учетом нового репозитория:
    sudo apt-get update
  4. Устанавливаем нужное:
    sudo apt-get install jenkins jenkins-cli ant openjdk-6-jdk

Сразу после установки у вас будет доступен сервер Jenkins по адресу http://localhost:8080/ .

Замечания:

Дополнительно установлен интерфейс командной строки для управления Jenkins. Его опции доступны по адресу http://localhost:8080/cli .

Пакеты ant и openjdk-6-jdk нужны для непосредственной работы заданий тестирования и сборки, самому Jenkins они не требуются.

Для начала работы желательно сходить в Центр управления плагинами и обновлениями: http://localhost:8080/pluginManager/ .

 

* Да, я тут лукавлю, ибо цель не в самом сервере НИ, а в том, что он умеет делать, но не всё сразу 😉

Комментариев нет »09.08.2012 10:55:21 | Ubuntu, Делаю | , ,

Бекап как проблема безопасности

Читать всё »

Комментариев нет »25.05.2012 11:06:08 | Делаю |

Грабельки deployment при наличии opcode кэша

Привет, PHP разработчик, администратор или релиз-менеджер! Наткнулся на интересное, спешу поделиться.

Дано:

Проект на PHP, одновременно работающий в режиме разработки («DEV», из SVN), а также боевом режиме («LIVE»), в который переводится ветка DEV после отлова багов. Сервер примечателен только тем, что PHP запускается через php-fpm и там включено opcode кэширование. У меня нижеследующее проявилось и при XCache и при APC.

Надо:

Перевести отлаженный проект из режима разработки в режим работы.

Решаем:

Итак, имеем примерно такую структуру проекта (ненужное вырезано):

.../dev/
       /app/
           /index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
       conf.php       : <?php $me = 'dev';
.../live/
       /app/
           /index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
       conf.php       : <?php $me = 'live';

Два виртуальных хоста в web сервере берут данные из …/dev/ и …/live/, где лежит соответствующий код. Всё работает, opcode кэш ускорят работу, все счастливы. Запрос на …/dev/app/index.php возвращает «dev», на …/live/app/index.php — «live».

Но вот пришла пора выложить код из DEV в LIVE как можно более быстро и без глюков. Понятно, что вариантов море, один из пришедших в голову был таков: для deployment использовать 2 команды переименования каталогов. Это на самом деле весьма «дешево»: операционная система сделает очень мало работы в очень короткое время, сбои крайне маловероятны:

mv .../live/app .../bak && mv .../dev/app .../live

И вот в очень короткое время мы переместили код. Всё хорошо? Нет! Запрос на …/live/app/index.php возвращает «dev», сайт работает с тестовыми данными разработчика! 🙁

Расследование:

Собственно, поиск причины был не сильно долгим. Мы переместили ветку файловой системы, идентификаторы файлов («inode») внутри ветки не поменялись и op-кэш наивно думает, что ничего не поменялось, т.к. он идентифицирует код по идентификатору файла. Ну и в итоге в окружении LIVE лежит файл, который запускается интерпретатором PHP со включенным файлом конфигурации на момент попадания в кэш — это был файл из DEV ветки. Вот так.

Итого мораль — при переносе дерева файлов PHP в рамках обработчика PHP с включенным opcode кэшированием вы продолжаете использовать старый закэшированный код, даже если включенные из перенесенных файлы поменялись.

Что делать?

Один из вариантов, и как мне кажется правильный — это запустить два экземпляра php-fpm обработчика. Отдельно для DEV и LIVE окружений. Или полностью исключить некоторые файлы из кэширования.

Комментариев нет »10.02.2012 12:38:48 | Делаю | , ,