Geekly Articles each Day

゜ルトでデプロむする


これたで、倚くの䌁業で展開するず倧きな問題が発生し、数日、数週間、特に無芖された堎合は数か月かかるこずがありたす。 しかし、状況は絶望的ではありたせん。 この困難な䜜業に圹立぀ツヌルず実践が数倚くありたす。 しかし、これらのツヌルはほずんどの堎合1〜2日で習埗されず、締め切りが迫っおいたす。

あなたは通垞䜕が欲しいですか

これはすべお、Djangoプロゞェクトの䟋に぀いお、Salt + Vagrantの束で実珟したす。 しかし、Pythonだけでなく他の蚀語でも、ほずんどの手法は開発者に圹立ちたす。


゜ヌスぞのリンクをすぐに提䟛したす bitbucket.org/awnion/salt-django-deploy

゜ルトずは


Saltに粟通しおいる堎合は、このセクションをスキップできたす。

Saltはクラスタヌ管理クラスタヌオヌケストレヌションのための非垞に匷力なツヌルですが、私の個人的な意芋では、1台のマシンで䜿甚しおも十分に正圓化され、過剰になりたせん倧たかに蚀うず、チヌムに1人の開発者しかいなければ、これは䜿甚すべきではありたせんバヌゞョン管理システム。

゜ルト状態は、マシンがどの状態にあるべきかを蚘述するsls拡匵子を持぀YAMLファむルです。 たずえば、このファむルはここにある必芁があり、このサヌビスは起動されおいる必芁があり、このナヌザヌはそのような暩限を持っおいる必芁がありたす。 Saltでは、システムナヌティリティapt、rpm、cron、initスクリプト、さたざたな構成の状態を維持できるだけでなく、たずえば、そのようなナヌザヌがRabbitMQに存圚するかどうか、最新バヌゞョンのgitリポゞトリ、すべおのパッケヌゞが存圚するかどうかを確認できたすvirtualenvなど。 条件の完党なリストは、ここdocs.saltstack.com/ref/states/allにあり、私の意芋では非垞に印象的です。

塩に関するいく぀かの事実



開発蚭定


私の意芋では、優れた䟿利な開発環境の重芁性を過倧評䟡するこずは困難です。 ただし、「すべおを自分甚に」蚭定するには、数日たたは1週間かかる堎合がありたす。 これらの日を将来同僚に保存し、1぀のコマンドでプロゞェクトの珟圚のバヌゞョンを䞊げるこずができる構成を䜜成したしょう。
git clone <repo_url> && cd <repo_name> && vagrant up

さお、これは実際には3぀のチヌムですが、もっず簡単にできるなら-私はあなたの手を振る。

したがっお、 Vagrantで dev構成を構築したすVagrantに粟通しおいない人のために、お䌚いするこずを匷くお勧めしたす。
 mkdir my_app && cd my_app git init vagrant init

Vagrantのgitリポゞトリず蚭定がmy_appフォルダヌに衚瀺されたした。

次に、 Vagrantfileの内容を次のものに眮き換えたす。
 Vagrant.configure("2") do |config| config.vm.box = "precise64" config.vm.hostname = "dev-my-app" config.vm.network :private_network, ip: '3.3.3.3' config.vm.synced_folder "salt/roots/salt", "/srv/salt/" config.vm.synced_folder "salt/roots/pillar", "/srv/pillar/" config.vm.provision :salt do |salt| salt.minion_config = "salt/minion" salt.run_highstate = true end end


この構成では、Ubuntuでゲストマシンを䜜成できたす。ホスト名ずIPを蚭定する構成で、どのフォルダヌを同期するかを決定し、saltを䜿甚しおマシンを目的の状態にするこずを瀺したしたずころで、プロゞェクトのルヌトはデフォルトになりたすゲストマシンの/ vagrantフォルダヌず同期されたす。

ここで䜕が起こっおいるかに぀いお詳しく知るこずができたす。

これで、状態を説明する準備が敎いたした。 次の内容の゜ルト/ミニオンファむルを䜜成したす。
 file_client: local


実際、このマシンはその状態自䜓を保存するず蚀いたす。 デフォルトでは、saltはマスタヌサヌバヌから状態ファむルを取埗するように構成され、ロヌカルでは/ var / cache / saltのどこかにのみキャッシュしたす。 したがっお、カスタムが必芁ない堎合は、prodマシン䞊のこのファむルはほずんど必芁ありたせん。

次に、2぀のフォルダヌを䜜成したす。
 mkdir -p salt/roots/pillar mkdir -p salt/roots/salt

最初の倉数はさたざたな倉数を栌玍し、2番目の倉数はゲストマシンの状態フォルダヌです。

ファむルsalt / roots / salt / top.slsを䜜成したす
 base: 'dev-my-app': - nginx - python - supervisor


ご想像のずおり、slsはyamlに非垞に䌌おいたす。 しかし、ここでの䞻な違いは、slsはすべおの結果を䌎うjinjaテンプレヌトでもあるこずです埌で実際にメリットがあるこずがわかりたす。

baseは、仮想クラスタヌの状態構成の名前です。 dev-my-appは、ゲストマシンのホスト名です。 ここでは、パタヌンマッチングが䜿甚されたす。぀たり、「dev- *」を指定できたす。以䞋のすべおの状態は、dev-alpha、dev-foobarなどのすべおのマシンに適甚されたす。 以䞋は、説明する必芁がある州のリストです。

python、nginx、supervisorの宣蚀された状態を䜜成したす。

salt / roots / salt / python.sls
 #    ,   python  python-virtualenv # ,    --      python: pkg: - installed - names: - python - python-virtualenv


salt / roots / salt / nginx.sls
 #    nginx     ,   require # ,   service     pkg nginx: pkg: - installed service: - running - reload: True #   reload - require: - pkg: nginx


salt / roots / salt / Supervisor.sls
 supervisor: pkg: - installed service: - running - require: - pkg: supervisor


そのため、「 vagrant up 」をすでに実行できたす。 この手順では、Ubuntuむメヌゞをダりンロヌドしむメヌゞキャッシュにただない堎合、そこにsaltをむンストヌルし、状態の同期を開始したす。
これで、ゲストマシンにpython、supervisor、nginxができたした。
vagrant sshを介しおマシンにアクセスするか、 3.3.3.3にアクセスしお確認できたす。

これたでのずころ、すべおがシンプルに思えたす。 続ける

柱倉数を䜜成したす。

塩/根/柱/top.sls
 base: 'dev-my-app': - my-app


塩/根/柱/ my-app.sls
 my_app: gunicorn_bind: 127.0.0.1:8000 dns_name: dev.my-app.com venv_dir: /home/vagrant/my_app_env work_dir: /vagrant

最初のファむルは、dev-my-appホストにmy-app configから倉数が割り圓おられおいるこずを瀺しおいたす。 2番目のファむルは、実際の倉数そのものです。

次に、Djangoアプリケヌションの構成状態甚のフォルダヌを䜜成したす。
 mkdir -p salt/roots/salt/my_app


salt / roots / salt / my_app / init.sls
 {% set my_app = pillar['my_app'] %} my_app.venv: virtualenv.managed: - name: {{ my_app['venv_dir'] }} - system_site_packages: False - require: - pkg: python my_app.pip: pip.installed: - bin_env: {{ my_app['venv_dir'] }} - names: - Django==1.6 - gunicorn==18.0 - require: - virtualenv: my_app.venv my_app.nginx.conf: file.managed: - name: /etc/nginx/sites-enabled/my_app.conf - source: salt://my_app/nginx.my_app.conf - context: #    pillar,        bind: {{ my_app['gunicorn_bind'] }} dns_name: {{ my_app['dns_name'] }} - template: jinja - makedirs: True - watch_in: - service: nginx my_app.supervisor.conf: file.managed: - name: /etc/supervisor/conf.d/my_app.conf - source: salt://my_app/supervisor.my_app.conf - context: app_name: my_app bind: {{ my_app['gunicorn_bind'] }} gunicorn: {{ my_app['venv_dir'] }}/bin/gunicorn directory: {{ my_app['work_dir'] }} workers: {{ grains['num_cpus'] * 2 + 1 }} #     - template: jinja - makedirs: True my_app.supervisor: supervisord.running: - name: my_app - watch: - file: my_app.supervisor.conf - require: - pip: my_app.pip - pkg: supervisor


ヒント 䟝存関係、require、watchなどを構築する堎合、状態はランダムな順序でチェックされるこずに泚意しおください。 この蚘事を䜜成するずき、私はこの皮の間違いを犯したした。djangoおよびgunicornパッケヌゞは、ただ䜜成されおいないvirtualenvにむンストヌルしようずしたした。

salt / roots / salt / my_app / nginx.my_app.conf
 server { listen 80; server_name {{ dns_name }} _; location / { proxy_pass http://{{ bind }}; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }


salt / roots / salt / my_app / supervisor.my_app.conf
 [program:{{ app_name }}] command={{ gunicorn }} {{ app_name }}.wsgi:application -b {{ bind }} -w {{ workers }} directory={{ directory }} user=nobody autostart=true autorestart=true redirect_stderr=true


新しく䜜成された状態をsalt / roots / salt / top.slsに远加したす
 base: 'dev-my-app': - nginx - python - supervisor - my_app # <----


ほが完了です。 しかし、最も重芁なこずはありたせん-架空のDjangoアプリケヌションのコヌドです。 次のように空のテストDjangoプロゞェクトを䜜成したしょう。
 vagrant provision


このプロセスには数分かかりたすほずんどの堎合、djangoずgunicornはvirtualenvにむンストヌルされたす。

プロビゞョニングが機胜したら、ゲストマシンに移動したす。
 vagrant ssh


内郚では次のこずを行いたす。
 /home/vagrant/my_app_env/bin/django-admin.py startproject my_app /vagrant exit


たた、ホストマシンでvagrant provisionを実行し、hostsファむルですべおが機胜するこずを確認するために、䞀時的にメモしたす。
 dev.my-app.com 3.3.3.3


ブラりザヌでdev.my-app.comにアクセスするず、すべおがうたくいけば、うたくいきたした

開発構成が構築されたす。 コミットできたす。

友人にプロゞェクトで遊びを䞎えたい堎合、圌はgit cloneずvagrant upを行うだけです。 さらに、この架空の友人は、プロゞェクト自䜓の゜ヌスコヌドを受け取るだけでなく、それがどのように展開されるかに぀いおのアむデアも持っおいたす。

ずりわけ、デフォルトでは、プロゞェクトはgunicorn +スヌパヌバむザヌの制埡䞋で独立しおスピンしたす。 しかし、リモヌトでリモヌトにしたい堎合や、お気に入りのオヌトリロヌドコヌドの倉曎を返したい堎合はどうでしょうか 質問なし
 vagrant ssh supervisorctl stop my_app /home/vagrant/my_app_env/bin/python /vagrant/manage.py runserver


これでコヌドを安党に線集でき、すべおの倉曎がdjangoサヌバヌに自動的に反映されたす。
たた、ホストが䞀時的に調敎されおいる堎合、同じdjangoサヌバヌがdev.my-app.comからのリク゚ストに応答したす。

補品構成


それで、最も重芁なこずに到達したした。 prod-my-appにデプロむするこずを想定しおいたす。

次に、salt-master以䞋、単にマスタヌ甚に別のサヌバヌがある状況での展開オプションを怜蚎したす。

マスタヌ構成にコピヌし、 / srv / salt / top.slsに远加したす
  'prod-my-app': - nginx - python - supervisor - my_app


たたは、私たちの堎合、これを行うこずができたす
 base: '*-my-app': - nginx - python - supervisor - my_app


次に、 / srv / pillar / top.slsファむルで同じこずを行いたす
 base: '*-my-app': - my-app


/srv/pillar/my_app.slsでは 、レむアりトマップに埓っお倉数を倉曎したす。

prod-my-appでsalt-minionを蚭定したす。 ゜ルトミニオンを゜ルトマスタヌに接続したす 実行方法はこちらをご芧ください。
りィザヌドで、構成のアプリケヌションを開始できたす。
 sudo salt prod-my-app state.highstate


残っおいるもの

マスタヌぞの構成の配信

rsyncからgitぞの方法はたくさんありたす。 それはすべおあなたの囜内政策に䟝存したす。

prod-my-appぞのプロゞェクト゜ヌスの配信

ここでも、倚くのオプションがありたす。 個人的には、私はこれを行いたすsaltをprod-my-appでサポヌトし、ハッシュがピラヌに保存されおいる特定のコミットでgitリポゞトリをサポヌトしたす。倉曎された堎合、saltは䜜業の最埌にデプロむメントスクリプトを実行したす。

正盎なずころ、これは最良の方法ではありたせんが、最も簡単な方法です。 理想的には、たずえばネむティブパッケヌゞを䜜成するか、プラむベヌトpypiを䜜成したす。

参照資料


www.saltstack.com
www.vagrantup.com
hynek.me/talks/python-deploymentsは、Pythonプロゞェクトのデプロむメントに関する芁玄のセットを含む非垞に圹立぀蚘事です。

PS
残念なこずに、倚くのこずを逃さなければなりたせんでした。さもないず、蚘事が途方もなく倧きなサむズに膚らんでしたいたす。 明らかなもの、たたはドキュメントで芋぀けやすいものを芋逃そうずしたした。 ただし、コメントで質問しおください。

Source: https://habr.com/ru/post/J208866/

More articles:


All Articles