To view applications listed in our site.pp, we can use the command puppet app show. This command reads our main manifest, and lists all applications and their components. In the following example, from the preceding code, we're deploying Myapp::Db to mysql and Myapp::Web to appserver:
[root@pe-puppet-master manifests]# puppet app show
Myapp[myapp]
Myapp::Db[myapp] => mysql
+ produces Sql[myapp]
Myapp::Web[myapp] => appserver
consumes Sql[myapp]
To simulate a deployment, we can use the puppet job plan command. We give it both an application and environment flag to let application orchestrator know which version of site.pp to use. This command primarily shows ordering, and you can see in the following results that mysql will be configured before appserver:
[root@pe-puppet-master manifests]# puppet job plan --application Myapp --environment production
+-------------------+------------+
| Environment | production |
| Target | Myapp |
| Concurrency Limit | None |
| Nodes | 2 |
+-------------------+------------+
Application instances: 1
- Myapp[myapp]
Node run order (nodes in level 0 run before their dependent nodes in level 1, etc.):
0 -----------------------------------------------------------------------
mysql
Myapp[myapp] - Myapp::Db[myapp]
1 -----------------------------------------------------------------------
appserver
Myapp[myapp] - Myapp::Web[myapp]
Use `puppet job run --application 'Myapp' --environment production` to create and run a job like this.
Node catalogs may have changed since this plan was generated.
By switching from puppet job plan to puppet job show, we actually deploy our code in an ordered fashion. The run first takes place on the mysql server, which produces information that will be consumed by the appserver node. This run ensures that the necessary components are fully deployed before attempting to deploy applications that depend on them:
Use `puppet job run --application 'Myapp' --environment production` to create and run a job like this.
Node catalogs may have changed since this plan was generated.
[root@pe-puppet-master manifests]# puppet job run --application 'Myapp' --environment production
Starting deployment ...
+-------------------+------------+
| Job ID | 8 |
| Environment | production |
| Target | Myapp |
| Concurrency Limit | None |
| Nodes | 2 |
+-------------------+------------+
Application instances: 1
- Myapp[myapp]
Node run order (nodes in level 0 run before their dependent nodes in level 1, etc.):
0 -----------------------------------------------------------------------
mysql
Myapp[myapp] - Myapp::Db[myapp]
1 -----------------------------------------------------------------------
appserver
Myapp[myapp] - Myapp::Web[myapp]
New job created: 8
Started puppet run on mysql ...
Finished puppet run on mysql - Success!
Resource events: 0 failed 4 changed 32 unchanged 0 skipped 0 noop
Report: https://pe-puppet-master/#/run/jobs/8/nodes/mysql/report
Started puppet run on appserver ...
Finished puppet run on appserver - Success!
Resource events: 0 failed 3 changed 130 unchanged 0 skipped 0 noop
Report: https://pe-puppet-master/#/run/jobs/8/nodes/appserver/report
Success! 2/2 runs succeeded.
We've now deployed a very simple ordered application. Our database will be fully up and running before the configuration of our wordpress server. In the next example, we'll allow for multiple wordpress servers and multiple load balancers to provide scaling to our application.