WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Deploy

Pizza Model

In the pizza model, deployment is analogous to assembling the pizza base and toppings, baking and delivering to the customer.

These tools are named instance specific. In the examples below XXXX is the name of the instance.

deployModuleXXXX

This task is for developer convenience - do not use for production configuration as no files are copied!

deployModuleXXXX is a convenience task associated with a single module build. It will create a new modules.d/ entry pointing to the file URI of the expanded module created when the project is built. By using the expanded location of the built module, then if the module is marked as , any subsequent build will be automatically hot-redeployed to netkernel with no restart.

Note - it does not copy the built module, it simply tells the NetKernel instance where to find it

For production configuration use deployCollectionXXXX (see below)

undeployModuleXXXX

This task is for developer convenience - do not use for production configuration as no files are copied!

undeployModuleXXXX is a convenience task associated with a single module build. It removes the modules.d/ entry for the expanded module.

Note - it does not touch the jar, it simply tells NetKernel not to use it any more

deployCollectionXXXX

deployCollectionXXXX downloads a collection of built modules from Maven and deploys them as a set to the specified instance.

This task requires a configured deploy collection of module dependencies. The declaration looks like...

//Boilerplate omitted

netkernel {

 deploy {
     collection = "skunkworks-project"
     module  group: 'skunkworks', name: 'urn.com.corp.project.x', version: '1.1.1'
     module  group: 'skunkworks', name: 'urn.com.corp.project.y', version: '1.1.1'
     module  group: 'skunkworks', name: 'urn.com.corp.project.z', version: '0.0.1'
 }

}

Notice this deploy declaration is not instance specific - so the same deployment collection can be applied to any declared instance.

The deploy configuration must have a collection - this is the name of the set of modules and will be used as the name of the set of modules in the NetKernel modules.d/ directory...

etc/modules.d/{collection}.xml

Each module statement uses the standard Gradle map dependency syntax to declare the repository artifacts (modules) to download and deploy to NetKernel. (Note that only the map syntax is supported and you must specify all of 'group', 'name' and 'version'.)

Setting up the deploy configuration allows you to reference the modules that have been built and installed to maven (see artifact name).

Example

Say, using the build/install tasks, you built a module with URI urn:com:company:project:module and version 1.1.1 and it was installed into Maven in the repository group big-corp-modules, then we could reference that as deploy dependency like this...

 deploy {
     collection = "project-modules"
     module  group: 'big-corp-modules', name: 'urn.com.company.project.module', version: '1.1.1'
 }

Version Dependency Resolution

A very powerful feature of the deploy configuration is that it fully supports Gradle/Maven version range syntax for resolution of the modules in the maven repository.

Therefore you can easily declare that a module should be the highest available version of the version 1.x.x major release but not the version 2.x.x generation like this...

 deploy {
     collection = "project-modules"
     module  group: 'skunkworks', name: 'urn.com.corp.project', version: '[1.0.0,2.0.0)'
 }

NetKernel Runlevel Option

You may optionally provide a runlevel for the specified module deployment as follows...

netkernel {

 deploy {
     collection = "skunkworks-project"
     module  group: 'skunkworks', name: 'urn.com.corp.project.x', version: '1.1.1', runlevel: 5
     module  group: 'skunkworks', name: 'urn.com.corp.project.y', version: '1.1.1', runlevel: 7
     module  group: 'skunkworks', name: 'urn.com.corp.project.z', version: '0.0.1'
 }
}

The runlevel attribute will be set on the module entry in the modules.d configuration file.

In pizza model terms deployCollectionXXXXX is the task to put the topping on the base.

undeployCollectionXXXX

undeployCollectionXXXX undeploys the named collection from the specified instance.

As with deployCollectionXXXX the collection name is determined from the deploy declaration.

deployLicenseXXXX

deployLicenseXXXX first empties the named instance's etc/license/ directory then searches the local build path for all *.lic license files and copies them into the NetKernel instance.

This task requires no configuration.

describeXXXX

describeXXXX provides a human readable report of the configuration of the named instance. Handy if you can't remember which instance is which.

cleanXXXX

cleanXXXX deletes the instance location completely - making the logical instance pristine.

Full Example: Download, install, configure a base instance and apply modules

The following build.gradle provides sufficient configuration to download and fully set up a new instance of NetKernel.

//Boilerplate omitted

//The repository where we'll get the deploy modules from
repositories {
    maven {
        url "file:/tmp/mvn/"
    }
}

//NetKernel plugin configuration
netkernel {

    //declare download edition and credentials
    download {
            edition = "EE"
            username = "foo"
            password = "baa"
    }

    //declare the apposite packages we want in the base
    apposite {
        packageList = ["lang-trl", "html5-frameworks"]
    }

    //declare the modules we've previously built and installed into the maven
    deploy {
         collection = "skunkworks-project"
         module  group: 'skunkworks', name: 'urn.com.corp.project.x', version: '1.1.1'
         module  group: 'skunkworks', name: 'urn.com.corp.project.y', version: '1.1.1'
         module  group: 'skunkworks', name: 'urn.com.corp.project.z', version: '0.0.1'
     }

    //declare our named instance called BASE
    instances
    {
        BASE
            {
                edition = "EE"
                location = "/opt/netkernel/NKEE-5.2.1-base/"
            }
    }
}

We can sequence the steps by issuing the following gradle command line...

gradle installBASE startBASE appositeUpdateBASE appositeConfigureBASE deployCollectionBASE stopBASE

This will do the following

  1. Download and install the BASE instance to /opt/netkernel/NKEE-5.2.1-base/
  2. Start the instance
  3. Synchronize and apply any updates from Apposite
  4. Configure this instance by installing lang-trl and html5-frameworks from Apposite
  5. Configure this instance by installing the module deployment collection from Maven
  6. Finally stop the instance

From our pizza model's perspective, this is maybe not a very good scenario - since its the equivalent of creating the base and applying the toppings all in one go.

In the next section we'll see how we can use the freezer to decouple the base configuration from the topping deployment.