The steps for deploying applications will be slightly different depending on the application. Instructions for deploying the Stackato sample applications can be found in the README.md file of each app.
To deploy an app to the Server VM, target the api endpoint URL with the stackato client:
$ stackato target api.stackato-xxxx.local
Use the stackato login command to authenticate with your username and password, then use the command:
$ stackato push
The output of the push command will be something like:
$ stackato push -n
Application Url: myapp.stackato-xxxx.local
Creating Application [myapp]: OK
Creating mysql Service [mydb]: OK
Binding Service [mydb]: OK
Uploading Application [myapp]:
Checking for available resources: OK
Packing application: OK
Uploading (30K): 100% OK
Push Status: OK
Staging Application [myapp]: OK
Starting Application [myapp]: OK
See each of these sections for language specific deployment details and examples:
.NET support via Mono is available with a Stackato add-on. Contact stackato-support@activestate.com for more information and access to the plugin.
Most applications should be able to run under Stackato with only a few changes.
A stackato.yml or manifest.yml file should be added to the root of your application to hold installation details as well as setup configuration instructions for your app.
If you want to use Stackato's data services, your code will need to make use of the connection details provided as environment variables to your code. To make sure your code works with both Stackato and independently, check for the existence of the specific environment variables Stackato provides. If they exist, use them, otherwise use your default settings.
See the Data Services section for further details.
Here is a list of environment variables visible during runtime (including hook processing, cron jobs and ssh commands):
See the Environment Variables section for further details.
The stackato push and stackato update commands will prompt the user for input or use options from the stackato.yml and manifest.yml files.
Note
The application name must be a valid hostname label (i.e. containing only alphanumeric characters and hyphens).
The push command implicitly stages and starts the application unless the --no-start option is used. With this option, applications are pushed in a pre-staged, stopped state where variables can be added (e.g. for use in staging hooks). The application can then be staged and started with the stackato start command or the Start button in the Management Console.
The client will display staging logs while pushing the application but will generally exit before any application logs are visible. To view the application logs, use the stackato logs command.
During the push process, Stackato includes only three file types:
All other special file types are ignored.
To prevent confusion or collisions, Stackato enforces uniqueness for URLs, application names, and service names at two different levels of scope (global and user/group):
Note
Cron commands are only executed on instance #0 of the app.
Cron commands can be provided either in a regular crontab file in the root directory of the app, or via the cron: section in stackato.yml (See stackato.yml Options).
The HOME and PATH environment variables, as well as all variables that start with PERL, PYTHON, STACKATO, VCAP, BUNDLE, LEIN, GEM, RACK, RAILS, or RUBY or http are exported to the top of the crontab file. When applicable, the following database related environment variables are also added: DATABASE_URL, MYSQL_URL, POSTGRESQL_URL, REDIS_URL, MONGODB_URL, and RABBITMQ_URL.
This happens after the pre-running hook has executed, so any changes made by those commands will be included in the crontab file.
After setting up environment variables, we copy the $HOME/crontab file, and finally the commands from the cron: section in stackato.yml. The resulting file is stored at $STACKATO_APP_ROOT/crontab.
Stackato automatically assigns to each application a URL made up of the application's name and the base URL for the system. An application named "myblog" deployed to a Stackato system at "api.stacka.to" would be given the URL "myblog.stacka.to".
In addition to this default URL, additional URLs can be set for an application using the stackato map command. The application will respond to requests on the mapped URL, provided a DNS record has been set up resolving to Stackato's external IP or hostname.
For example, to map a URL to an existing application on Stackato:
$ stackato apps
+--------------+---+--------+----------------------------------+------------+
| Application | # | Health | URLS | Services |
+--------------+---+--------+----------------------------------+------------+
| myapp | 1 | 100% | myapp.stacka.to | |
+--------------+---+--------+----------------------------------+------------+
$ stackato map myapp mydomain.com
+--------------+---+--------+----------------------------------+------------+
| Application | # | Health | URLS | Services |
+--------------+---+--------+----------------------------------+------------+
| myapp | 1 | 100% | myapp.stacka.to | |
| | | | mydomain.com | |
+--------------+---+--------+----------------------------------+------------+
If DNS is configured correctly, requests to "mydomain.com" will resolve transparently to "myapp.stacka.to".
Note
Application URLs are allocated on a "first come, first serve" basis, and are reserved for the user who created the URL.
URLs can be mapped to multiple applications owned by the same user, which can be useful for A/B testing. Stackato routes requests to the mapped URL randomly between all available app instances.
Using the 'myapp.stacka.to' example above, you could push 'myapp-v2' (e.g. a more recent revision) then map 'mydomain.com' to that app as well. You can access the specific versions directly using 'myapp.stacka.to' and 'myapp-v2.stacka.to', and use 'mydomain.com' to round robin between available instances of both versions:
+-------------+---+---------+--------------------+-------------+
| Application | # | Health | URLS | Services |
+-------------+---+---------+--------------------+-------------+
| myapp | 5 | RUNNING | myapp.stacka.to | |
| | | | mydomain.com | |
| myapp-v2 | 1 | RUNNING | myapp-v2.stacka.to | |
| | | | mydomain.com | |
+-------------+---+---------+--------------------+-------------+
As you gain confidence with the new revision, you can increase the number of instances of 'myapp-v2' (i.e. phasing that version into production rather than cutting over) and eventually unmap 'mydomain.com' from the original 'myapp'.
With multi-instance applications on Stackato, the Router will distribute requests among all instances. Without session management, the end user could access different application instances with each HTTP request instead of connecting to the same instance that started their session.
Cloud-enabled applications should use a shared database (e.g. Redis), cache (e.g. Memcached), or filesystem as a back end for session management. Some examples of this approach are:
Stackato's default router ("router2g") does no special handling of JSESSIONID or SESSIONID cookies.
The NGINX-based legacy router supports sticky sessions using JSESSIONID or SESSIONID, but relying on this method can result in uneven traffic distribution and is unreliable in multi-router cluster configurations.