Разработав консольную утилиту, вы решаетесь опубликовать её на PyPI. Ну правда, что может быть лучше, чем сделать её доступной через pip install? Погуглив, что для этого надо, вы, возможно, наткнётесь на единственный найденный мной пост по теме, который мало того что от 2014 года, так ещё и требует от вас создать кучу папок и файлов для совершенно ненужных (вам) вещей.

Как же решить эту задачу без лишней головной боли в 2019 году? Я уже задавался этим вопросом и поэтому, прочитав тонну документации, создал для вас этот туториал. Вот пошаговая инструкция.

1. Создайте аккаунт на PyPI (ссылка для регистрации)

2. Создайте точку входа в приложение (например, файл entry.py со следующим содержимым)

def main():
    print("It's alive!")

3. Установите poetry

curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
source $HOME/.poetry/env

(poetry можно установить и по-другому, например, pip install --user poetry — прим. перев.)

4. Создайте окружение

cd myproject # Перейдите в папку проекта, который будем паковать
poetry init

5. Настройте консольную команду (для этого добавьте следующие строки в появившийся файл pyproject.toml)

[tool.poetry.scripts]
APPLICATION-NAME = 'entry:main'

APPLICATION-NAME надо поменять на имя консольной команды.

6. Опубликуйте утилиту! (используйте имя пользователя и пароль из шага 1)

poetry publish --username PYPI_USERNAME --password PYPI_PASS --build

Готово! Теперь другому человеку для установки достаточно всего двух команд:

$ sudo pip install PROJECT-NAME
$ APPLICATION-NAME

Где PROJECT-NAME — это имя, которое вы дали проекту на шаге 4, а APPLICATION-NAME — это имя команды из шага 5.

Обновление версии

Всякий раз, когда вы хотите обновить модуль, просто измените номер версии в файле pyproject.toml:

version = "0.1.0"

И повторите шаг 6:

poetry publish --username PYPI_USERNAME --password PYPI_PASS --build

Бонус: настраиваем Travis для авто-публикации

Добавьте следующие строки в файл .travis.yml

language: python
dist: xenial
before_install:
  - curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
  - source $HOME/.poetry/env
install:
  - poetry install
script:
  - poetry build
deploy:
  - provider: script
    skip_cleanup: true
    script: poetry publish --username $PYPI_USER --password $PYPI_PASS
    on:
      branch: master
      python: '3.7'
      tags: true

И установите переменные окружения PYPI_USER и PYPI_PASS на travis-ci.com. После этого можно будет публиковать пакет с помощью команд:

git tag -a v1.2 # Replace version number with yours
git push --tags

С недавних пор я начал использовать новый менеджер под названием Poetry. Именно о нём сегодня пойдёт речь.

Функциональные возможности Poetry:

• Управление зависимостями через toml файл (прощай, requirements.txt)


• Автоматическое создание изолированного виртуального окружения Python (теперь не нужно для этого вызывать virtualenv)


• Удобное создание пакетов (отныне не нужно копипастить создавать setup.py каждый раз)


• poetry.lock файл для фиксирования версий зависимостей

А особенно радует тандем при работе с pyenv. О pyenv я писал три года назад.

Установка

Исходный код проекта лежит на github. Для установки необходимо выполнить команду:

curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python

Если установка прошла успешно, то убедиться в этом можно вызвав:

$ poetry --version
Poetry 0.12.8

Стартуем!

Создаём новый проект my-demo-project:

$ poetry new my-demo-project

Заходим в папку:

$ cd my-demo-project/
~/my-demo-project$ ls
README.rst my_demo_project pyproject.toml tests

Poetry автоматически создал все необходимые файлы для будущего пакета, но наибольший интерес представляет файл с названием pyproject.toml, этот файл можно рассматривать как продвинутую альтернативу старичку requirements.txt. Взглянем на содержимое:

[tool.poetry]
name = "my-demo-project"
version = "0.1.0"
description = ""
authors = ["Your Name you@example.com"]

[tool.poetry.dependencies]
python = "^3.6"

[tool.poetry.dev-dependencies]
pytest = "^3.0"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

Формат файла TOML. Раздел tool.poetry предназначен для описания проекта: название, версия, краткая информация о проекте и т.д. Далее следует tool.poetry.dependencies, именно здесь будут указаны все production зависимости. Их можно указать вручную (привет, requirements.txt), но мы так делать не будем (привет, npm!). Раздел tool.poetry.dev-dependencies предназначен для зависимостей во время разработки (привет, pytest, tox!)

Добавляем зависимости

Давайте добавим к проекту зависимость в виде Luigi.

~/my-demo-project$ poetry add luigi==2.8.0

Creating virtualenv my-demo-project-py3.6 in /home/user/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies... (24.1s)

Package operations: 12 installs, 0 updates, 0 removals

Writing lock file
  - Installing docutils (0.14)
  - Installing lockfile (0.12.2)
  - Installing six (1.11.0)
  - Installing atomicwrites (1.2.1)
  - Installing attrs (18.2.0)
  - Installing more-itertools (4.3.0)
  - Installing pluggy (0.8.0)
  - Installing py (1.7.0)
  - Installing python-daemon (2.1.2)
  - Installing tornado (4.5.3)
  - Installing luigi (2.8.0)
  - Installing pytest (3.10.1)

Обратите внимание, что Poetry автоматически создал виртуальное окружение через virtualenv при добавлении пакета (т.к. ранее оно не было создано). Все окружения находятся по пути ~/.cache/pypoetry/virtualenvs

Если снова открыть pyproject.toml, то можно увидеть новую запись в разделе зависимостей:

[tool.poetry.dependencies]
python = "^3.6"
luigi = "=2.8.0"

Всю "грязную" работу за нас делает Poetry. Чтобы добавить зависимость для разработки достаточно указать флаг —dev:

$ poetry add tox --dev

Using version ^3.5 for tox
Updating dependencies
Resolving dependencies... (6.3s)
Package operations: 4 installs, 0 updates, 0 removals

Writing lock file
  - Installing filelock (3.0.10)
  - Installing toml (0.10.0)
  - Installing virtualenv (16.1.0)
  - Installing tox (3.5.3)

Смотрим содержимое pyproject.toml ещё раз:

[tool.poetry.dev-dependencies]
pytest = "^3.0"
tox = "^3.5"

Чтобы удалить зависимость нужно выполнить:

~/my-demo-project$ poetry remove luigi

Сборка пакета

Отныне забудьте про головную боль с ручным созданием setup.py, прописыванием туда всех зависимостей и запоминанием команд для сборки через pip. Всё стало в разы проще. Чтобы собрать python пакет выполните:

~/my-demo-project$ poetry build

Building my-demo-project (0.1.0)
 - Building sdist
 - Built my-demo-project-0.1.0.tar.gz
 - Building wheel
 - Built my_demo_project-0.1.0-py3-none-any.whl

В папке dist будут сформированы пакеты. Чтобы поделиться своим творением с другими разработчиками, например через pypi, выполните:

~/my-demo-project$ poetry publish

Окружение

Для активации виртуального окружения необходимо выполнить команду:

~/my-demo-project$ poetry shell

Вывод

Проект Poetry появился 28 февраля 2018 года, последняя версия 0.12.8. Инструмент молодой, но перспективный и быстроразвивающийся. Уже сейчас он на голову выше старичка pip и по функциональным возможностям и по удобству использования. Советую вам его попробовать и поделиться мнением в комментариях к этой статье. За более подробной информацией об инструменте советую заглянуть на сайт с документацией.

Объемы данных в современных системах растут с каждым днем и тот объем, который еще вчера считался достаточным, сегодня уже не способен удовлетворить текущие требования. Также дешевеют носители данных, особенно это касается твердотельных накопителей, что рано или поздно поставит администратора перед необходимостью апгрейда дисковой подсистемы. Но как быть, если вы используете программный RAID в Linux? В этой статье мы рассмотрим наиболее часто встречающийся сценарий с заменой дисков на более емкие и расширением объема массива.

Несмотря на то, что в качестве примера мы использовали Debian 9 все нижеизложенное будет справедливо для любого базирующегося на Debian дистрибутиве, а с небольшими поправками (там, где касается установки загрузчика) для любой Linux-системы.

По условиям задачи в нашем распоряжении есть виртуальная машина, в которой на двух дисках собраны два RAID1 для корневого раздела и подкачки, диски являются загрузочными. Мы специально выбрали такую конфигурацию, чтобы охватить все возможные сценарии и показать общие принципы работы с программным RAID при его расширении. При этом используемая конфигурация не является оптимальной или рекомендуемой, мы создали ее сугубо в образовательных целях.

Итак, у нас в системе используются два виртуальных жестких диска объемом 20 ГБ которые мы хотим заменить на новые виртуальные диски объемом в 30 ГБ желательно без существенного простоя системы.

Прежде всего ознакомимся с текущей конфигурацией дисковой подсистемы. Будет очень полезно выполнить перезагрузку и войдя в BIOS уточнить с какого именно физического диска мы загружаемся.

В нашем случае это первый физический диск. Теперь загрузимся в систему и выполним команду:

lsblk

ее вывод позволяет в удобном виде увидеть структуру текущей дисковой подсистемы.

Как можно увидеть, в нашем случае на двух физических жестких дисках sda и sdb расположены два программных массива raid1: md0 с корневой файловой системой и md1 с разделом подкачки объемом 16,8 ГБ и 3,2 ГБ соответственно.

Следующим шагом нам нужно посмотреть разметку на физических дисках, это можно сделать при помощи утилиты fdisk, но лучше использовать ее аналог с псевдографическим интерфейсом - cfdisk. Запустим ее с указанием интересующего нас диска:

cfdisk /dev/sda

Здесь мы видим, что диск имеет таблицу разделов MBR (Label: dos в шапке) и содержит первичный раздел sda1 объемом 16,8 ГБ типа fd Linux RAID, а также логический раздел sda2, в котором находится еще один раздел типа fd Linux RAID размером 3,2 ГБ - sda5.

Запомним эти данные, так как аналогичную по структуре разметку нам нужно будет воспроизвести на новом жестком диске. Для этого нам нужно заменить один из старых дисков массива на новый, так как загрузились мы с первого физического диска, т.е. sda, то заменить нам следует sdb. Поэтому пометим его как сбойный для каждого из расположенных на нем массивов:

mdadm -f /dev/md0 /dev/sdb1
mdadm -f /dev/md1 /dev/sdb5

Теперь можно выключить сервер и физически заменить старый жесткий диск на новый. После этого загрузимся и выполним команду:

fdisk -l

Как видим в системе появился новый неразмеченный диск sdb объемом 30 ГБ. Теперь следует разметить его:

cfdisk /dev/sdb

Первым шагом указываем тип таблицы разделов, так как у нас уже используется MBR, то выбираем dos.

Теперь нам нужно создать аналогичную по структуре sda разметку, но с новыми разделами разделов. Единственное условие - они не должны быть меньше уже имеющихся. В нашем случае мы создадим первичный раздел объемом 26 ГБ и укажем для него тип Linux raid autodetect (fd) используя для этого кнопку Type утилиты.

Затем запишем изменения кнопкой Write. На оставшемся месте создадим расширенный раздел (extended) и внутри его еще один раздел Linux raid autodetect (fd). В итоге у вас должна получиться разметка аналогичная по структуре sda, но с новыми размерами разделов.

Теперь добавим вновь созданные разделы в массивы:

mdadm --add /dev/md0 /dev/sdb1
mdadm --add /dev/md1 /dev/sdb5

После чего убедимся, что начался процесс ресинхронизации:

cat /proc/mdstat

И обязательно дождемся ее окончания. Система в это время будет доступной, но может испытывать проблемы с производительностью из-за повышенной нагрузки на дисковую подсистему, поэтому желательно запланировать данный процесс на нерабочее время. После успешной ресинхронизации вывод команды будет выглядеть следующим образом:

Вроде бы все хорошо, но не забываем про загрузчик, на новом диске его нет. Поэтому выполним:

dpkg-reconfigure grub-pc

Принимаем значения по умолчанию пока не появится окно с выбором дисков, указываем установку загрузчика на все физические диски, выбирать RAID-массив не надо.

Перезагружаем систему, выбрав в BIOS в качестве загрузочного устройства новый жесткий диск. Если все было сделано правильно, то вы загрузитесь уже с нового жесткого диска. Теперь нужно пометить sda как сбойный и исключить его из массива:

mdadm -f /dev/md0 /dev/sda1
mdadm -f /dev/md1 /dev/sda5

Выключаем сервер, физически заменяем диск на новый, загружаемся. Проверяем дисковую конфигурацию:

Как видим, теперь у нас в системе появился новый неразмеченный диск sda, но так как нам уже не нужно создавать разделы с отличным от sdb размером, то просто скопируем разметку с одного диска на второй, для этого используем еще одну утилиту sfdisk:

sfdisk -d /dev/sdb | sfdisk /dev/sda

При выполнении данной операции важно не перепутать диски местами, иначе вы скопируете разметку с пустого диска на диск с данными, что приведет к их утере. Первым следует указать диск источник, вторым - целевой диск. Плюс данной операции - вместе с разметкой скопируется также загрузчик.

Снова добавим разделы в массив:

mdadm --add /dev/md0 /dev/sda1
mdadm --add /dev/md1 /dev/sda5

Дождемся окончания ресинхронизации:

Перезагрузимся несколько раз и убедимся, что загрузка возможна с обоих физических дисков. Теперь снова выполним команду:

lsblk 

и внимательно изучим вывод:

Несмотря на то, что мы увеличили размер sda1/sdb1 и sda5/sdb5 размеры массивов md0 и md1 остались неизменными. Но если мы вспомним, что программный RAID в Linux строится поверх разделов, то все станет на свои места. Это аналогично тому, что если бы мы заменили жесткий диск в системе на более емкий, но перенесли раздел без изменения размера.

Что делать? Расширить объем массива, для этого выполните команды:

mdadm --grow /dev/md0 --size=max
mdadm --grow /dev/md1 --size=max

Что у нас получилось?

Вроде бы все хорошо. Но если для раздела подкачки этого достаточно, то с разделами, содержащими файловую систему не все так просто. В этом можно убедиться, выполнив:

df -h

Из ее вывода видно, что размер файловой системы не изменился и нам по-прежнему доступно около 17 ГБ. Но здесь нет никакой ошибки, если мы вспомним, что программный RAID является для системы аналогом диска, который содержит раздел с файловой системы, то поймем, что несмотря на то, что мы увеличили размер диска, нам следует также увеличить размер раздела с данными. Для этого выполним:

resize2fs /dev/md0

Вот теперь можно считать процесс расширения массива законченным, мы расширили все необходимые разделы и теперь можем использовать все доступное пространство новых дисков. Сам процесс может показаться несколько сложным, но если представить всю эту систему как матрешку, когда одни разделы вкладываются в другие - то все станет на свои места и система вновь станет стройной и логичной.

А в заключение не будет лишним напомнить, что все проведенные нами операции несут потенциальный риск полной потери данных, поэтому перед тем, как выполнять указанные в статье действия создайте полную резервную копию вашей системы.

Get-WindowsOptionalFeature -Online | ft >$env:userprofile\desktop\features.txt
Get-WindowsOptionalFeature -Online -FeatureName NetFX3

Mount-WindowsImage -ImagePath $env:ua\wim\install.wim -Index 1 -Path $env:ua\mount
Disable-WindowsOptionalFeature -Path $env:ua\mount -FeatureName Microsoft-Hyper-V-All
Get-WindowsOptionalFeature -Path $env:ua\mount -FeatureName Microsoft-Hyper-V-All
Dismount-WindowsImage -Path $env:ua\mount -Save

Введение

• /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
• /run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
• /etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

• .service – системный сервис
• .target — группа юнитов systemd
• .automount – точка автомонтирования файловой системы
• .device – файл устройства, распознанного ядром
• .mount – точка монтирования файловой системы
• .path – файл или директория в файловой системе
• .scope – процесс, созданный извне
• .slice – группа иерархически организованных юнитов, управляющая системными процессами
• .snapshot – сохраненное состояние менеджера systemd
• .socket – сокет межпроцессного взаимодействия
• .swap – Свап-устройство или свап-файл (файл подкачки)
• .timer – таймер systemd

Основные функции systemd в CentOS 7

• Активация, основанная на сокетах. Во время загрузки systemd прослушивает сокеты для всех системных сервисов, поддерживает этот тип активации и передает сокеты этим сервисам сразу после старта сервисов. Это позволяет systemd не только запускать сервисы параллельно, но также дает возможность перезапускать сервисы без потери любых отправленных им сообщений, пока сервисы были недоступны. Соответствующий сокет остается доступным и все сообщения выстраиваются в очередь.
• Активация, основанная на D-Bus. Системные сервисы, использующие D–Bus для межпроцессного взаимодействия, могут быть запущены по требованию, когда клиентское приложение пытается связаться с ними.
• Активация, основанная на девайсах. Системные сервисы, поддерживающие активацию, основанную на девайсах, могут быть запущены, когда определенный тип оборудования подключается или становится доступным.
• Активация, основанная на путях. Системные сервисы могут поддерживать этот вид активации, если изменяется состояние папки или директории.
• Снепшоты системных состояний. Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.
• Управление точками монтирования и автомонтирования. Systemd отслеживает и управляет точками монтирования и автомонтирования.
• Агрессивная параллелизация Systemd запускает системные сервисы параллельно из-за использования активации, основанной на сокетах. В комбинации с сервисами, поддерживающими активацию по требованию, параллельная активация значительно уменьшает время загрузки системы.
• Транзакционная логика активации юнитов. До активации и деактивации юнитов systemd вычисляет их зависимости, создает временную транзакцию и проверяет целостность этой транзакции. Если транзакция нецелостная, systemd автоматически пытается исправить ее и удалить не требующиеся задания из нее до формирования сообщения об ошибке.
• Обратная совместимость с инициализацией SysV. SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.

Управление сервисами

• systemctl start name.service – запуск сервиса.
• systemctl stop name.service — остановка сервиса
• systemctl restart name.service — перезапуск сервиса
• systemctl try-restart name.service — перезапуск сервиса только, если он запущен
• systemctl reload name.service — перезагрузка конфигурации сервиса
• systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса
• systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive
• systemctl list-units --type service --all – отображение статуса всех сервисов
• systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
• systemctl disable name.service – деактивирует сервис
• systemctl reenable name.service – деактивирует сервис и сразу активирует его
• systemctl is–enabled name.service – проверяет, активирован ли сервис
• systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы
• systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
• systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

Работаем с целями (targets) Systemd

• poweroff.target (runlevel0.target) – завершение работы и отключение системы
• rescue.target (runlevel1.target) – настройка оболочки восстановления
• multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
• graphical.target (runlevel5.target) – настройка графической многопользовательской системы
• reboot.target (runlevel6.target) – выключение и перезагрузка системы

Выключение и перезагрузка системы

Управление systemd на удаленной машине

Типичный systemd .service

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

Дополнительная информация

Настройка брадмаузера