Get a new version of the Java project in Tomcat from the test environment to the production environment using Ansible-playbook

Source: Internet
Author: User
Tags vars

I. Description of the Environment

Server with Ansible installed: 192.168.13.45

Test environment server: 192.168.13.49

/home/app/api-tomcat/webapps/api.war a new version of the war package location for the test environment

Production Environment server: 192.168.13.51

/home/app/api-tomcat/webapps/api.war for production Environment War package location/HOME/APP/API-TOMCAT/WEBAPPS/API for production environment Project location/home/app/tomcat.bak/ api/webapps-timestamp for the old version WebApps backup location/home/app/newwar/api.war A temporary storage location for the new version of the war package obtained from the test environment/home/app/newwar/ Location of the API for temporary storage after decompression of the new version of the war package

All in app user execution

Second, the preparation of Ansible-playbook yml file 1, upgrade

All the note text at the beginning of the # is removed when used, because YML is not annotated

#生产环境主机的ip, this can also be a/etc/ansible/hosts defined group name- hosts: 192.168.13.51# variable, using variables in the Yml file allows the entire file to be upgraded on different hosts, The use of variables is {{  variable name &nbsp,}}, if the variables in the task after the colon, you must add the colon after the whole sentence with double quotation marks "", because the Yml file automatically identifies the contents of the curly braces after the colon as a list, such as the shell: "{{ oldhome  }}/bin/startup.sh "  vars: #测试环境IP地址     testip: 192.168.13.49# The location of the project in the test environment     testhome: /home/app/api-tomcat/webapps# the name of the project War package in the test environment      warname: api.war# the location of the project's Tomcat in the production environment     oldhome: /home/app/api-tomcat# The location of the WebApps backup directory in the old version of the project in your production environment     backupwebapps: /home/app/tomcat.bak# The location of the new version of the war package obtained from the test environment     newwar: /home/app/newwar# the name of the directory after the new version of the war package was extracted      zipname: api# an account used throughout the remote Automation operation, where all operations from the production environment to the test environment are   remote_user: app# specific actions performed by the app user   tasks:    - name:  production Environment Delete/home/app/newwar directory, If the directory does not exist then the error is ignored (the reason for deleting this directory is to create a new directory, to ensure that the entire YML file can be executed more than once, ignore_errors to ignore the error return value)       file: path={{ newwar }} state=absent       ignore_errors: yes    - name:  production environment Create/home/app/newwar directory, Change the permissions, (where Recurse is the recursive creation directory, state is the file type is directory)       file: path={{ newwar }}  recurse=yes mode=775 owner=app group=app state=directory    -  name:  Copy the new version from the test environment 192.168.13.49/home/app/api-tomcat/webapps/api.war package to the 192.168.13.51/home/app/of the production environment Newwar directory, the following operations are done in a production environment       shell: scp [email protected]{{  testIP }}:{{ testhome }}/{{ warname }} {{ newwar }}     - name:  to/home/app/newwar recursive permissions (because the corrective action is performed as an app user, so be sure to ensure that permissions for the app's permissions)        file: dest={{ newwar}} recurse=yes mode=775 owner=app group= App    - name:  Unzip/home/app/newwar/api.war package in/home/app/newwar/api directory       shell:  unzip -oq {{ newwar }}/{{ warname }} -d {{ newwar }}/{ { zipname }}     - name:  re-/home/app/newwar the permissions (to ensure the new version is the app's permissions)        file: dest={{ newwar}} recurse=yes mode=775 owner=app group=app     - name:  Create a directory to back up older versions of WebApps/home/app/tomcat.bak/api and change the recursive permissions        file: path={{ backupwebapps }}/{{ zipname }} recurse=yes mode= 775 owner=app group=app state=directory    - name:  Backup/home/app/ Api-tomcat/webapps to Directory/home/app/tomcat.bak/api/webapps-timestamp (this backup directory is used for rollback)        Shell: cp -a {{ oldhome }}/webapps {{ backupwebapps }}/{{ zipname  }} /webapps-' date +%y%m%d%h%m '     - name:  The kill process stops the service. Ignore the error return value (this way to ensure that the old version stops running, otherwise conflicts will occur)       shell: ps -ef  | grep {{ oldhome }} | grep -v grep | xargs kill       ignore_errors: yes    - name:  The kill process stops the service. Ignore the error return value (make sure the old version is no longer running again)       shell: ps -ef | grep  {{ oldhome }} | grep -v grep | xargs kill       ignore_errors: yes    - name:  kill process again to stop the service. Ignore Error return value       shell: ps -ef | grep {{ oldhome }}  | grep -v grep | xargs kill      ignore_ errors: yes    - name:  View the result of stopping the service, whether the process alsoIn       SHELL: PS -EF | GREP {{ OLDHOME }}     - name:  Delete old version of/home/app/api-tomcat/webapps/api.war package        file: path={{ oldhome }}/webapps/{{ warname }} state=absent       ignore_errors: yes    - name:  Delete old version of/home/app /API-TOMCAT/WEBAPPS/API Program Directory       file: path={{ oldhome }}/webapps /{{ zipname }} state=absent      ignore_errors: yes     - name:  Copy the new version directory/home/app/newwar/api to the/home/app/api-tomcat/webapps directory        shell: cp -a {{ newwar }}/{{ zipname }} {{  oldhome }}/webapps/    - name:  Copy new version of war package/home/app/newwar/api.war package to/ Under the Home/app/api-tomcat/webapps directory      shell: cp -a {{ newwar }}/{{ warname }}  {{ oldhome }}/webapps/    - name:  Start Service/home/app/api-tomcat/bin/ Startup.sh (source is to load the JDK environment variable, NOHUP is to ensure that the yml run out of process still does not exit)       shell:  "source  /etc/profile;nohup {{ oldhome }}/bin/startup.sh & "    -  name:  See if there is a service started in the process       shell: ps -ef | grep  {{ oldhome }}
2. Rollback
#生产环境主机地址- hosts: 192.168.13.51# variable and upgrade the same   vars:    testIP:  192.168.13.49    testhome: /home/app/api-tomcat/webapps     warname: api.war    oldhome: /home/app/api-tomcat     backupwebapps: /home/app/tomcat.bak    newwar: /home/app/newwar     zipname: api# remote operation is still using the app user   remote_user: app# the following actions are   tasks in the production environment:     - name: kill process mode stop service. Ignore error return value       shell:  Ps -ef | grep {{ oldhome }} | grep -v grep | xargs  kill      ignore_errors: yes    - name:  kill process mode stop service. Ignore error return value       shell: ps -ef | grep {{  oldhome }} | grep -v grep | xargs kill      ignore_errors: yes     - name:  kill process again to stop the service. Ignore error return value       shell: ps  -ef | grep {{ oldhome }} | grep -v grep | xargs  kill      ignore_errors: yes    - name:   View the results of the stop service. Is the process still       shell: ps -ef | grep {{  oldhome }}    - name:  Delete/home/app/api-tomcat/webapps directory        file: path={{ oldhome }}/webapps state=absent     - name:  Display the WebApps directory for the most recent backup in/home/app/tomcat.bak/api/, the directory name should be webapps-recent timestamp        shell: ls -r {{ backupwebapps }}/{{ zipname }} | head  -1    - name:  copy backup/home/app/tomcat.bak/api/webapps-latest timestamp, to project and rename/home/app/api-tomcat/webapps       shell: cp -a {{ backupwebapps }}/{{ zipname }}/$ (LS  -R {{ BACKUPWEBAPPS }}/{{ ZIPNAME }} | HEAD -1)  {{  oldhome }}/webapps    - name:  Start Service/home/app/api-tomcat/bin/startup.sh       shell:  "source /etc/profile;nohup {{ oldhome }}/bin/ startup.sh & "    - name:  Delete the backup file that you just rolled back        shell: rm -rf {{ backupwebapps }}/{{ zipname }}/$ (ls -r {{  backupwebapps }}/{{ zipname }}    - name:  See if there are services started in the process       shell: ps -ef | grep {{ oldhome }}
III. upgrade operation and Precautions 1. Key-free operation before upgrade

Ansible host 192.168.13.45

#在app用户下生成密钥ssh-keygen-t rsa# Send the public key to the test environment ssh-copy-id-i. ssh/id_rsa.pub [email protected] #发送公钥到生产环境ssh-copy-id-i. ssh/ id_rsa.pub [email protected]

Production Environment Host 192.168.13.51

#在app用户下生成密钥ssh-keygen-t rsa# Send the public key to the test environment ssh-copy-id-i. ssh/id_rsa.pub [Email protected]

For business security, ansible host and production environment host, test environment host is interoperable. The production environment host can connect to the test environment host, but the test environment host cannot connect to the production environment host, so here the test environment host does not need to send the key to the production environment host

2. Upgrade and Rollback

Upgrade

Ansible-playbook/home/app/api.yml-v

Rolling back

Ansible-playbook/home/app/api-rollback.yml-v

Ansible-playbook followed by the Yml file path written earlier,-V is to display detailed execution information

3. Attention

If you perform an upgrade and rollback of the yml file in Jenkins, be sure to send the public key of the Jenkins user to the production environment host and the test environment host, otherwise the permissions error will be reported

The host to be operated on must be filled into the/etc/ansible/hosts

Two yml files have been validated in a production environment

Original article, N17_ letter Wind, if reproduced, please indicate the source: http://www.178linux.com/64052

Get a new version of the Java project in Tomcat from the test environment to the production environment using Ansible-playbook

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.