я сам подумываю о переходе на ansible тк 90% ф-ционала мне не нужны) ну и всякие стейты например для django — устаревшие
по поводу реюза, можно всякие gitfs использовать для каких-то общих вещей, но пока с этим не игрался, а вот всякие https://github.com/saltstack-formulas меня не всегда устраивают
за таргетинг спс, проверю, я просто уже не помню где у меня костыль, а где корректное использование) к-во issue на гитхабе уже начинает пугать
можем продолжить дискуссию в jabber'e slav0nic@jabber.ru или на почте slav0nic0@gm…
Да, самый корректный вариант — CI и деплой с него, но увы на последних проектах этого нет) посему все вручную и ничего интересного, по поводу доступа тоже особо не парюсь. но если очень захотеть. то можно salt.renderers.gpg использовать.
Еще интересно, у вас получается и стейты и пиллар хранятся в одном репозитории + Saltfile?
Используются ли мульти-окружения (dev\stg\etc\prod) и к ним девелоперы имеют доступ?
С кастомными grains в salt-ssh не всё так просто, приходится ухищряться, grains: в ростере работает только в версиях 2016+: ➤ cat salt/roots/pillar/top.sls
base:
'*':
- base
- packages
- services
- python
- git
- nginx
'staging': # G@ не работает, хотя в свежих версиях не тестил
- match: list
- staging
...
➤ cat salt/roots/pillar/staging.sls
postgres: # например пеереопределяем не весь pillar, а только нужные поля, остальное все `наследуется` из базовых
version: 9.5
после чего в стейте добавляю в context `role` (это хак, но я не уверен что кастомный грейин исправвили в последних версиях salt-ssh, надо проверить): {{ pillar.project.project_path }}/settings/local.py:
file.managed:
- source: salt://files/django/settings_production.py
- template: jinja
- user: ubuntu
- context:
role: {{ grains.role }}
ну и далее просто `{% if role=='staging' %}` в шаблонах или grains.role в стейтах
рекомендую глянуть http://www.saltstat.es/posts/meta/intermediate.html
вы наверно один на проекте, с Saltfile команде не обязательно знать что такое salt, достаточно их salt-ssh ключи добавить на сервер и рассказать что команду надо запускать из каталога где лежит Saltfile
я год ждал фикса касательно salt-ssh и mercurial, после чего пришлось разобраться самому и отправить пулреквесты)
в целом salt-ssh реализованы не все фишки (например с таргетингом по grains не все так просто) и основная часть работ ведётся по работе над фиксами в режиме minion
касательно недостатков: за 2 года часто что-то ломали после выхода новых патчей и стабильность отставляла желать лучшего, но в последних версиях этого года все вроде более-менее гладко
похоже автор ещё не открыл для себя Saltfile =) использовать /etc/salt и /srv/salt не обязательно + это очень неудобно если у вас куча проектов, на много удобней хранить состояния в репозитории и просто настроить Saltfile
что-то вроде:
обычно у заказчика требующего python/ruby найдётся 10-20уе/мес на нормальный VPS…
хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)
Sybase это делает через in-memory database в репликационном сервере, после чего делает булк лоад в OLAP, при этом отбрасывая «промежуточные мусорные запросы»
спасибо конечно, но до «advanced» тут ещё далеко. ipython — это довольно сложная система с обширным ф-ционалом. Часть фишек раскрыта в книге Python for Unix and Linux System Administration (доку читать довольно скучно)
по поводу реюза, можно всякие gitfs использовать для каких-то общих вещей, но пока с этим не игрался, а вот всякие https://github.com/saltstack-formulas меня не всегда устраивают
за таргетинг спс, проверю, я просто уже не помню где у меня костыль, а где корректное использование) к-во issue на гитхабе уже начинает пугать
можем продолжить дискуссию в jabber'e slav0nic@jabber.ru или на почте slav0nic0@gm…
получается
tree salt/
salt/
├── master
├── roots
│ ├── pillar
│ │ ├── base.sls
│ │ ├── client-staging.sls
│ │ ├── git.sls
│ │ ├── nginx.sls
│ │ ├── packages.sls
│ │ ├── python.sls
│ │ ├── services.sls
│ │ ├── staging.sls
│ │ └── top.sls
│ └── salt
│ ├── backup.sls
│ ├── cron.sls
│ ├── django.sls
│ ├── files
│ │ ├── backup
│ │ │ └── aws_config
│ │ ├── crontab
│ │ ├── django
│ │ │ └── settings_production.py
│ │ ├── nginx
│ │ │ ├── htpasswd
│ │ │ └── nginx.conf
│ │ └── uwsgi
│ │ └── vassal.ini
│ ├── git.sls
│ ├── nginx.sls
│ ├── packages.sls
│ ├── postgresql.sls
│ ├── python.sls
│ ├── top.sls
│ └── uwsgi.sls
└── roster
➤ cat salt/master
file_roots:
base:
- ./salt/roots/salt
pillar_roots:
base:
- ./salt/roots/pillar
➤ cat Saltfile
salt-ssh:
config_dir: ./salt/
#roster
staging:
host: xxxxx
user: ubuntu
sudo: True
priv: ~/.ssh/id_rsa
minion_opts:
grains:
role: staging
С кастомными grains в salt-ssh не всё так просто, приходится ухищряться, grains: в ростере работает только в версиях 2016+:
➤ cat salt/roots/pillar/top.sls
base:
'*':
- base
- packages
- services
- python
- git
- nginx
'staging': # G@ не работает, хотя в свежих версиях не тестил
- match: list
- staging
...
➤ cat salt/roots/pillar/staging.sls
postgres: # например пеереопределяем не весь pillar, а только нужные поля, остальное все `наследуется` из базовых
version: 9.5
после чего в стейте добавляю в context `role` (это хак, но я не уверен что кастомный грейин исправвили в последних версиях salt-ssh, надо проверить):
{{ pillar.project.project_path }}/settings/local.py:
file.managed:
- source: salt://files/django/settings_production.py
- template: jinja
- user: ubuntu
- context:
role: {{ grains.role }}
ну и далее просто `{% if role=='staging' %}` в шаблонах или grains.role в стейтах
рекомендую глянуть http://www.saltstat.es/posts/meta/intermediate.html
Да, имел в виду разрабов.
я вот выкинул fabric и перешёл на такой подход
в целом salt-ssh реализованы не все фишки (например с таргетингом по grains не все так просто) и основная часть работ ведётся по работе над фиксами в режиме minion
касательно недостатков: за 2 года часто что-то ломали после выхода новых патчей и стабильность отставляла желать лучшего, но в последних версиях этого года все вроде более-менее гладко
что-то вроде:
хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)
ну и про «хостинг» (хостинги в том виде, в котором они есть в РНР, малопопулярны в других языка) с py3.2 — docs.webfaction.com/software/python.html