1 - Preamble
- eas changeset identifier: e7696197ffe0 85b4845
- sfeas_config changeset identifier: 91ac3c3c21bf ca66c28
This deployment will consist of the following general steps:
- Perform the steps below in the San Francisco production environment (SF PROD *) and then test the application in that environment.
- If the application passes its tests, then perform the steps below in the disaster recovery production environment (DR PROD *) and then test the application in that environment.
- In the unlikely event that things go very badly, we would switch over to the previous version of the application in the disaster recovery production environment (DR PROD *).
2 - Web Application into Maintenance Mode
Place the Web servers into maintenance mode (SF PROD WEB, DR PROD WEB).
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
cd /opt/rh/httpd24/root/var/www/html
sudo ./set_eas_mode.sh MAINT |
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
cd /opt/rh/httpd24/root/var/www/html
sudo ./set_eas_mode.sh MAINT |
- DR PROD WEB is in maintenance mode: httphttps://10easdrweb.255sfgov.8.116org/
3 - Backup the EAS Databases ???SHOULD BE HANDLED BY DBAS???
Log onto SF PROD DB and back up the EAS databases. The database backup script simply creates an additional daily backup, which are periodically purged from the file system, so there is no need to be concerned about the accumulation of "forgotten" database backups.
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
sudo -u postgres -i
/home/dba/scripts/dbbackup.sh > /var/tmp/dbbackup.log |
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
# You should receive an email notifying you of the status of the backup.
# The database backup log file is another source of information about the
# outcome of the backups. Note that an empty database backup log file
# indicates that the backups were successful.
ls -la /var/tmp/dbbackup.log
cat /var/tmp/dbbackup.log
# The existence of the database backups can also be confirmed directly
# from the command line:
ls -la /mnt/backup/pg/daily/easproddb.sfgov.org-* |
- Database backup was verified
...
There is no DR PROD AUTO machine.
...
5 - Upgrade Geoserver (DR)
- Edgar will fulfill service request SER0377256 (Upgrade GeoServer on DR PROD GEOX)
- Configure GeoServer on DR PROD GEOX. You can use these commands:
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
sudo curl -O https://bitbucket.org/sfgovdt/easx/raw/1.4.1/geoserver/deploy_geoserver_init.sh
sudo chmod 700 ./deploy_geoserver_init.sh
sudo ./deploy_geoserver_init.sh |
- Check that the DR PROD GEOX configurations deployed properly via geoserver web admin.
5 - Upgrade Geoserver (SF)
- Edgar will fulfill service request SER0377256 (Upgrade GeoServer on SF PROD GEOX)
- Configure GeoServer on SF PROD GEOX. You can use these commands:
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
cd C:\apps\
python eas_automation_deploy.py eas_automationsudo curl -O https://bitbucket.org/sfgovdt/easx/raw/1.4.1/geoserver/deploy_geoserver_init.sh
sudo chmod 700 ./deploy_geoserver_init.sh
sudo ./deploy_geoserver_init.sh |
- Check that the SF PROD GEOX configurations deployed properly via geoserver web admin.
5 - Deploy the Web Application (SF)
- Deploy the Web application to SF PROD WEB per the instructions that are on * * WEB Server. If you staged the uncompressed repositories ahead of time, then you . You can use these commands to deploy the Web application:
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
cd /opt/rh/httpd24/root/var/www/html
sudo ./deploy_eas_init.sh e7696197ffe085b4845 91ac3c3c21bfca66c28 samuelvaldezrgaston |
- Test the application to make sure everything works.
6 - Deploy the Web Application (DR)
Note |
---|
title | Disable Database Replication? |
---|
|
You will not be able to log into the Web application in the disaster recovery production environment (DR PROD WEB) if database replication is running. |
- If testing in the San Francisco production environment (SF PROD *) is successful, then deploy the Web application to the disaster recovery production environment (DR PROD *) with steps that parallel those that were performed in the San Francisco production environment (* PROD WEB only).
- Make sure that the disaster recovery production environment Web application functions correctly.
- Testing the disaster recovery production environment Web application surfaced this issue: DR PROD WEB/GEO cannot connect to DR PROD DB
- Place the disaster recovery Web server (DR PROD WEB) into standby mode:
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
cd /opt/rh/httpd24/root/var/www/html
sudo ./set_eas_mode.sh STANDBY_DR |
7 - Release Notifications
- Remove 1.34.8 1 from the road map.
- Publish the blog post for this release. Ideally, this blog post would have already been drafted. An example is Release 1.3.6.
- Log on to the automation machine (SF PROD AUTO) and run the following job to send the release announcement to stake holders:
Code Block |
---|
language | bash |
---|
linenumbers | true |
---|
|
cd C:\apps\eas_automation\automation\src
python job.py --action EXECUTE --job announce_new_release --env SF_PROD |
- This release announcement will also be sent to the Yammer All Company group, so check your email inbox for the request from Yammer to post the release announcement there.
- Return to Step 26 of the release checklist because you are all done here!