Resin Cloud Deployment Reference

From Resin 3.0

(Difference between revisions)
Jump to: navigation, search
(→Proposed but not Implemented 4.0.25 Deploy and Rollback)
(→Promoting an app from preview mode to production)
Line 632: Line 632:
  
 
Promotes blog that is currently in preview mode into production.
 
Promotes blog that is currently in preview mode into production.
 +
 +
 +
== Cluster deployment NOT IMPLEMENTED UNTIL Resin 4.0.25 (coming soon) ==
 +
 +
<code>
 +
<pre>
 +
resinctl | grep config
 +
  config-deploy - deploys configuration directory
 +
  config-copy - copies configuration
 +
  config-list - lists all deployed configurations
 +
  config-list-ls - list contents of config dir (ex. ./lib)
 +
  config-list-cat - list contents of config file
 +
  config-undeploy - undeploys a config
 +
</pre
 +
</code>
 +
 +
 +
At times you need to include things like jar files that are available to more than one application.
 +
Resin allows you to deploy these to cluster (which can be 1 to hundreds of servers) with one simple command.
 +
 +
Let's say you have an application that relies on MySQL.
 +
 +
 +
Setup an RDS database using MySQL 5.1.7 (or as close to your MySQL as possible).
 +
 +
I use the same username password to make it simple. The only part that is going to change for sure is the URL.
 +
 +
 +
By default resin uses the /etc/resin/resin.properties file. You could add these properties to /etc/resin/resin.properties.
 +
 +
'''/etc/resin/resin.properties on resin server'''
 +
<code>
 +
<pre>
 +
 +
blogdb.url : blogdb.cvolnlau763z.us-east-1.rds.amazonaws.com
 +
blogdb.user : bloguser
 +
blogdb.password : roofoo
 +
 +
</pre>
 +
</code>
 +
 +
These properties will vary for dev, production, qa, etc. And once they are set, they will not change often.
 +
 +
You could test locally by copying this file (blog-database.xml) to /etc/resin/resin.d/.
 +
 +
 +
'''/etc/resin/resin.d/database.xml''' blog-database.properties under /etc/resin/resin.d.
 +
<code>
 +
<pre>
 +
<resin xmlns="http://caucho.com/ns/resin"
 +
      xmlns:resin="urn:java:com.caucho.resin">
 +
 +
<database jndi-name="jdbc/blogdb">
 +
        <driver type="com.mysql.jdbc.Driver">
 +
                <url>jdbc:mysql://${blogdb.url}:3306/blogdb</url>
 +
                <user>${blogdb.user}</user>
 +
                <password>${blogdb.password}</password>
 +
        </driver>
 +
</database>
 +
</resin>
 +
</pre>
 +
</code>
 +
 +
 +
The problem now is that you don't have a mysql.jar file and you will get a class not found exception when the apps starts up.
 +
 +
 +
 +
If you are using maven locally you can copy mysql from the maven local repo as follows:
 +
 +
 +
 +
Find and copy the mysql jar file from the maven local repo to Resin as follows:
 +
 +
Find it:
 +
 +
<code>
 +
<pre>
 +
$ find ~/.m2/repository/ -name "*mysql*.jar"
 +
/home/rick/.m2/repository/mysql/mysql-connector-java/5.1.18/mysql-connector-java-5.1.18.jar
 +
</pre>
 +
</code>
 +
 +
 +
Now deploy it
 +
 +
<code>
 +
<pre>
 +
  $ sudo cp ~/.m2/repository/mysql/mysql-connector-java/5.1.18/mysql-connector-java-5.1.18.jar \
 +
                    /usr/local/share/resin/lib/
 +
 +
</pre>
 +
</code>
 +
 +
Or you can use yum to get the mysql driver as follows:
 +
 +
Next install the mysql driver.
 +
$ sudo yum install mysql-connector-java
 +
$ sudo cp /usr/share/java/mysql-connector-java.jar /usr/local/share/resin/lib/
 +
 +
 +
The problem with this approach is that things work for you locally for /blog if it relies on mysql being managed under jndi:jdbc/blogdb, but all of your remote deployments will fail unless you manually add the mysql jar to each server.

Revision as of 23:55, 6 December 2011

  1. Deploying to a local server
    1. Deploying to a staging server (locally)
    2. Deploying to a preview staging server (locally)
  2. Deploying to a remote server
    1. Setting up a user and password
    2. Deploying to a remote server
  3. Setting up a cloud topology
    1. Deploying to the Triad
    2. license-add enabling Resin features
  4. Deploy to a staging server
    1. Setting up load balancer to not to deploy to staging server
  5. Common tasks
    1. Deploying a new application deploy
    2. Listing current versions of deployed application
    3. Undeploying a new application
    4. Using deploy-copy to promote a release to production
    5. Using deploy-copy to rollback a release that was deployed to production
    6. Installing mysql driver for a web application using config-deploy
    7. Showing what is in remote config with config-list-ls and config-list-cat
  6. web-app-deploy settings 


$ resinctl | grep deploy 
  deploy - deploys an application
  deploy-copy - copies an application
  deploy-list - lists all deployed applications
  deploy-restart - restarts an application
  deploy-start - starts an application
  deploy-stop - stops an application
  undeploy - undeploys an application
  config-deploy - deploys configuration directory
  config-undeploy - undeploys a config

$ resinctl | grep config 
  config-deploy - deploys configuration directory
  config-copy - copies configuration
  config-list - lists all deployed configurations
  config-list-ls - list contents of config dir (ex. ./lib)
  config-list-cat - list contents of config file
  config-undeploy - undeploys a config


Contents

Deploying to a local server

Deploy commands available 

$ resinctl help deploy


Output:
usage: bin/resin.sh [-conf <file>] [-server <id>] deploy -user <user> \
-password <password> [options] <war-file>

description:
   deploys application specified in a <war-file> to resin server

options:
   -conf <file>          : resin configuration file
   -server <id>          : id of a server
   -address <address>    : ip or host name of the server
   -port <port>          : server http port
   -user <user>          : user name used for authentication to the server
   -password <password>  : password used for authentication to the server
   -host <host>          : virtual host to make application available on
   -name <name>          : name of the context to deploy to, defaults to war-file name
   -stage <stage>        : stage to deploy application to, defaults to production
   -version <version>    : version of application formatted as <major.minor.micro.qualifier>
   -m <message>          : commit message

Turning on versioning: 

$ cat /etc/resin/resin.properties | grep deploy

Output:
deploy_versioning : true



$ sudo grep "web-app-deploy" -A 1 /etc/resin/resin.xml 

Output:
      <web-app-deploy path="webapps" versioning="${deploy_versioning}"
                      expand-preserve-fileset="WEB-INF/work/**"/>

"if true, use the web-app's numeric suffix as a version"

Run deploy command passing location of war file. 

$ resinctl deploy ./target/blog-0.1.0.war -name blog 

Output:
Deployed production/webapp/default/blog from \
./target/blog-0.1.0.war to hmux://127.0.0.1:6800

To see the deployed you can use resinctl deploy-list 

$ resinctl deploy-list

Output:
production/webapp/default/blog

  • TODO explain production/webapp/default/blog
  • TODO add a table
  • TODO explain how to start up a server with different staging servers


Now undeploy it: 

$ resinctl undeploy blog

Output:
Undeployed blog from hmux://127.0.0.1:6800

At this point there should be nothing 

$ resinctl deploy-list

Now deploy it with versioning: 

$ resinctl deploy ./target/blog-0.1.0.BUILD-SNAPSHOT.war -name blog -version 0.1.0 

Output:
Deployed production/webapp/default/blog-0.1.0 from \
./target/blog-0.1.0.BUILD-SNAPSHOT.war to hmux://127.0.0.1:6800

Blog application is under the version 0.1.0 

$ resinctl deploy-list

Output:
production/webapp/default/blog-0.1.0

  • TODO explain production/webapp/default/blog-0.1.0
  • TODO add a table
  • TODO explain how to start up a server with different staging servers

Deploying to a staging server

Deploy to staging server. 

$ resinctl deploy ./target/blog-0.1.0.BUILD-SNAPSHOT.war -name blogz -version 0.1.0 -stage staging

Output
Deployed staging/webapp/default/blogz-0.1.0 from \
./target/blog-0.1.0.BUILD-SNAPSHOT.war to hmux://127.0.0.1:6800

The staging name is logical. You can call it anything. The app will not be served unless the server is started with this staging name.

Showing items deployed to staging server. 

$ resinctl deploy-list
production/webapp/default/blog-0.1.0
staging/webapp/default/blogz-0.1.0


The /blog works but /blogz does not work because server is by default setup as production server.

/blog works because server is setup for production 

$ wget localhost:8080/blog
...
HTTP request sent, awaiting response... 200 OK

/blogz does not work because server is not setup for production 

$ wget localhost:8080/blogz
...
HTTP request sent, awaiting response... 404 Not Found

To run the server as a staging server do the following: 

$ resinctl stop

Output:
Resin/4.0.24 stopped -server 'app-0' for watchdog at 127.0.0.1:6600


$ resinctl help start

Output:
usage: bin/resin.sh [-options] start

where options include:
   -conf <file>          : select a configuration file
   -data-directory <dir> : select a resin-data directory
   -join-cluster <cluster>       : join a cluster as a dynamic server
   -log-directory <dir>  : select a logging directory
   -resin-home <dir>     : select a resin home directory
   -root-directory <dir> : select a root directory
   -server <id>          : select a <server> to run
   -watchdog-port <port> : override the watchdog-port
   -verbose              : print verbose starting information
   -preview              : run as a preview server
   -debug-port <port>    : configure a debug port
   -jmx-port <port>      : configure an unauthenticated jmx port
   -stage <staging-name> : The stage the server is serving (default production)


$ sudo resinctl start -stage staging

Output:
Resin/4.0.24 launching watchdog at 127.0.0.1:6600
Resin/4.0.24 started -server 'app-0' for watchdog at 127.0.0.1:6600


$ wget localhost:8080/blogz
...
...
HTTP request sent, awaiting response... 200 OK


Deploying to a preview staging server 


$ resinctl deploy ./target/blog-0.1.0.BUILD-SNAPSHOT.war -name blogp -version 0.1.0 -stage preview

Output
Deployed preview/webapp/default/blogp-0.1.0 from \
./target/blog-0.1.0.BUILD-SNAPSHOT.war to hmux://127.0.0.1:6800

$ resinctl deploy-list

Output
preview/webapp/default/blogp-0.1.0
production/webapp/default/blog-0.1.0
...


Restart the server in preview stage, since preview staging is a common thing, you can just use the -preview command. 


$ resinctl stop

Output:
Resin/4.0.24 stopped -server 'app-0' for watchdog at 127.0.0.1:6600

$ sudo resinctl start -preview

Output:
Resin/4.0.24 launching watchdog at 127.0.0.1:6600
Resin/4.0.24 started -server 'app-0' for watchdog at 127.0.0.1:6600


Now the preview blog site is available. 

$ wget localhost:8080/blogp
...
HTTP request sent, awaiting response... 200 OK

Deploying to a Remote Server

Setup the remote box (Install Resin)

You need to create a user name and password. 

REMOTE SERVER $ resinctl generate-password -user rick -password dogbones

Output:
admin_user : rick
admin_password :  {SSHA}JmojvNUU4OpTOw0/SESRsnpEHejxkhZZ


Modify resin.properties 


REMOTE SERVER$ cat  /etc/resin/resin.properties

Output:
admin_user : rick
admin_password :  {SSHA}JmojvNUU4OpTOw0/SESRsnpEHejxkhZZ
admin_remote_enable : true
...

Now from the local server deploy your app as follows: 

LOCAL SERVER $ resinctl deploy target/blog-0.1.0.BUILD-SNAPSHOT.war -name blogdb \ 
-address 192.168.248.168 -port 8080 -user rick -password dogbones

You can verify that the deploy worked as follows: 

$ resinctl deploy-list -address 192.168.248.168 -port 8080 -user rick -password dogbones

Output:
production/webapp/default/blog
...


Working with deploy-copy to release, and rollback

Deploy version to archive. 

$ resinctl deploy ./target/blog-0.1.0.BUILD-SNAPSHOT.war -name blog -stage archive -version 0.1.0

Output:
Deployed archive/webapp/default/blog-0.1.0 from \
./target/blog-0.1.0.BUILD-SNAPSHOT.war to hmux://127.0.0.1:6800


List versions deployed. 

$ resinctl deploy-list

Output:
archive/webapp/default/blog-0.1.0


Copy deployment to production 

$ resinctl deploy-copy -source blog -source-stage archive \
-source-version 0.1.0  -target blog

Output:
copied archive/webapp/default/blog-0.1.0 to production/webapp/default/blog


$ resinctl deploy-list

Output:
archive/webapp/default/blog-0.1.0
production/webapp/default/blog


When you deploy this way you must start the app as follows: 

$ resinctl deploy-start blog

Output:
'production/webapp/default/blog' is started

Then you would deploy copy a different version to rollback or promote a different version to prod.

In review of the above, we have decided to make the process a bit easier.

The following section has not yet been implemented, but is slated for 4.0.25.



Proposed but not Implemented 4.0.25 Deploy and Rollback

The following section has not yet been implemented, but is slated for 4.0.25.


Deploy version to archive. 

$ resinctl deploy ./target/blog-0.1.0.BUILD-SNAPSHOT.war -name blog -archive-version 0.1.0

Output:
Deployed archive/webapp/default/blog-0.1.0 from \
./target/blog-0.1.0.BUILD-SNAPSHOT.war to hmux://127.0.0.1:6800
into production \


List versions deployed with all option. 

$ resinctl deploy-list -all

Output:
Tag                Ver.     DD-MM-YYYY-HH:MM:SS
archive/webapp/default/blog-0.1.0     0.1.0    05-12-2011-13:00:00
production/webapp/default/blog         0.1.0    05-12-2011-13:00:00


Later you decide to update to a new version likely after weeks or months of hard development. The line marked with production/webapp/default/blog is the /blog that is deployed in the running server. 


$ resinctl deploy ./target/blog-0.2.0.BUILD-SNAPSHOT.war -name blog -archive_version 0.2.0

Output:
Deployed archive/webapp/default/blog-0.2.0 from \
./target/blog-0.1.0.BUILD-SNAPSHOT.war to hmux://127.0.0.1:6800
deployed into production.


At this point the following will be deployed: 

$ resinctl deploy-list -all

Output:
Tag                  Ver.     DD-MM-YYYY-HH:MM:SS
archive/webapp/default/blog-0.1.0     0.1.0    05-12-2011-13:00:00
archive/webapp/default/blog-0.2.0     0.2.0    05-01-2012-11:00:00
production/webapp/default/blog         0.2.0    05-01-2012-11:00:00


Even after rigorous load testing and QA testing, a critical bug was found in 0.2.0 blog and now you need to quickly rollback to a previous version.

To rollback to a previous version use the deploy-archive as follows: 

$ resinctl deploy-archive blog -version 0.1.0

Output:
Deployed archive/webapp/default/blog-0.1.0 to hmux://127.0.0.1:6800 \
into production


Even after rigorous load testing and QA testing, a critical bug was found in 0.2.0 blog and now you need to quickly rollback to a previous version.

To rollback to a previous version use the deploy-rollback as follows: 

$ resinctl deploy-rollback blog -version 0.1.0

Output:
Deployed archive/webapp/default/blog-0.1.0 to hmux://127.0.0.1:6800 \
into production



Even after rigorous load testing and QA testing, a critical bug was found in 0.2.0 blog and now you need to quickly rollback to a previous version.

To rollback to a previous version use the rollback as follows: 

$ resinctl rollback blog -version 0.1.0

Output:
Deployed archive/webapp/default/blog-0.1.0 to hmux://127.0.0.1:6800 \
into production


Even after rigorous load testing and QA testing, a critical bug was found in 0.2.0 blog and now you need to quickly rollback to a previous version.

To rollback to a previous version use the deploy-stage as follows: 

$ resinctl deploy-stage blog -stage archive  -version 0.1.0

Output:
Deployed archive/webapp/default/blog-0.1.0 to hmux://127.0.0.1:6800 \
into production

We will need a deploy-stage no matter what for managing preview servers. 

 NOTE:

I think we go with deploy-rollback and deploy-stage. They do almost the same thing. Rollback is a bit more self documenting. You use deploy-rollback for rollbacks and you use deploy-stage for promoting an app to production. 

 END NOTE:


Now after the rollback the deployed servers should look like this. 

$ resinctl deploy-list -all

Output:
Tag                Ver.     DD-MM-YYYY-HH:MM:SS
archive/webapp/default/blog-0.1.0     0.1.0    05-12-2011-13:00:00
archive/webapp/default/blog-0.2.0     0.2.0    05-01-2012-11:00:00
production/webapp/default/blog         0.1.0    05-12-2011-13:00:00


Notice that 0.1.0 is now in production.


Promoting an app from preview mode to production

Options 

$ resinctl deploy-promote blog 

Output:
Deployed preview/webapp/default/blog to hmux://127.0.0.1:6800 \
into production

Promotes blog that is currently in preview mode into production.


Cluster deployment NOT IMPLEMENTED UNTIL Resin 4.0.25 (coming soon) 

resinctl | grep config 
  config-deploy - deploys configuration directory
  config-copy - copies configuration
  config-list - lists all deployed configurations
  config-list-ls - list contents of config dir (ex. ./lib)
  config-list-cat - list contents of config file
  config-undeploy - undeploys a config
</pre
</code>


At times you need to include things like jar files that are available to more than one application.
Resin allows you to deploy these to cluster (which can be 1 to hundreds of servers) with one simple command.

Let's say you have an application that relies on MySQL.


Setup an RDS database using MySQL 5.1.7 (or as close to your MySQL as possible).

I use the same username password to make it simple. The only part that is going to change for sure is the URL.


By default resin uses the /etc/resin/resin.properties file. You could add these properties to /etc/resin/resin.properties.

'''/etc/resin/resin.properties on resin server'''
<code>
<pre>

blogdb.url : blogdb.cvolnlau763z.us-east-1.rds.amazonaws.com
blogdb.user : bloguser
blogdb.password : roofoo

These properties will vary for dev, production, qa, etc. And once they are set, they will not change often.

You could test locally by copying this file (blog-database.xml) to /etc/resin/resin.d/.


/etc/resin/resin.d/database.xml blog-database.properties under /etc/resin/resin.d. 

<resin xmlns="http://caucho.com/ns/resin"
      xmlns:resin="urn:java:com.caucho.resin">

<database jndi-name="jdbc/blogdb">
        <driver type="com.mysql.jdbc.Driver">
                 <url>jdbc:mysql://${blogdb.url}:3306/blogdb</url>
                 <user>${blogdb.user}</user>
                 <password>${blogdb.password}</password>
         </driver>
</database>
</resin>


The problem now is that you don't have a mysql.jar file and you will get a class not found exception when the apps starts up.


If you are using maven locally you can copy mysql from the maven local repo as follows:


Find and copy the mysql jar file from the maven local repo to Resin as follows:

Find it: 

$ find ~/.m2/repository/ -name "*mysql*.jar"
/home/rick/.m2/repository/mysql/mysql-connector-java/5.1.18/mysql-connector-java-5.1.18.jar


Now deploy it 

  $ sudo cp ~/.m2/repository/mysql/mysql-connector-java/5.1.18/mysql-connector-java-5.1.18.jar \ 
                     /usr/local/share/resin/lib/

Or you can use yum to get the mysql driver as follows:

Next install the mysql driver. 

$ sudo yum install mysql-connector-java
$ sudo cp /usr/share/java/mysql-connector-java.jar /usr/local/share/resin/lib/


The problem with this approach is that things work for you locally for /blog if it relies on mysql being managed under jndi:jdbc/blogdb, but all of your remote deployments will fail unless you manually add the mysql jar to each server.

Retrieved from "http://wiki3.caucho.com/index.php?title=Resin_Cloud_Deployment_Reference&oldid=4317"
Personal tools