Creating automated JDeveloper 12.1.3 & Oracle XE 11gR2 environment provisioning – using Vagrant and Puppet

Standing on the shoulders of many smart and persistent friends, peers and colleagues, I was able to fairly quickly concoct the Vagrant and Puppet configuration that allows automated provisioning of a VirtualBox VM that runs Ubuntu (64bit Linux) with Oracle Database XE 11gR2 and JDeveloper 12.1.3 (with ADF 12.1.3). With a few command line actions, the creation of a clean and preconfigured VM is done in the background.

This article gives a brief description of how I put together the configuration for Vagrant and Puppet to install Oracle Database XE and JDeveloper. The final picture looks like the figure.

Note: I started from the excellent contribution by Michael Medin (see GitHub: https://github.com/mickem/adf-12c-enviornment ) and tweaked his configuration just a little to support JDeveloper 12.1.3 (instead of 12.1.2). My own contribution was very limited – although by doing it my understanding has increased substantially. The work done by my colleagues Jaap Poot and Edwin Biemond has been extremely valuable (especially their recent article for Java Magazine, the Magazine for the Dutch NLJUG).

Edwin Biemond has been the greatest inspiration in getting excited about Vagrant, Puppet and bascially provisioning in general. Big kudos!

The only external requirements or preparations are:

• download and install Oracle VirtualBox (see resources)
• download and install Vagrant (see resources)
• download the Oracle Database 11gR2 XE installation file – oracle-xe-11.2.0-1.0.x86_64.rpm.zip
• download the Oracle JDeveloper 12.1.3 installation file – jdev_suite_121300_linux64.bin
• fetch the sources discussed in this article from GitHub, either by cloning the repository using Git or by downloading the sources as a zip-file – https://github.com/lucasjellema/adf-12-1-3-vm

Steps:

• download all and install some of the prerequisite stuff (see above)
• create a new Vagrant project (a folder, a generated configuration file and a few manual alterations) => this is enough to create a bare bones VirtualBox VM image
• configure the Vagrant file to use Puppet as a provider => this means that Puppet is added to the VM image and the specified Puppet resources are executed from within the VM after it is built and started
• create the Puppet main manifest file – base.pp in this case => this file references the classes and resources that are required for the VM; initially this file will do very little at all – the real work is added once we create modules for installing the XE database and JDeveloper
• create the Puppet module for installing the Oracle XE database (based on Michael Medin’s work) and include the classes from this module from the base.pp main manifest file => at this point we can run Vagrant to create the Linux VirtualBox image with the XE 11gR2 database inside (including the unlocked HR schema)
• create the Puppet module for installing Oracle JDeveloper 12.1.3 (based again on Michael Medin’s work) and include the classes from this module from the base.pp main manifest file => at this point we can run Vagrant to create the Linux VirtualBox image with the XE 11gR2 database inside as well as JDeveloper
• create a bonus Puppet module to install a sample database schema with tables and demo data

Create the VirtualBox image with Vagrant

The first step is a very simple one. We will use Vagrant to help us create (automatically) a VirtualBox image with Ubuntu 64-bit Linux set up. This local image is based on one of the predefined Vagrant boxes published on the Vagrant website: Ubuntu precise 64 VirtualBox, at http://files.vagrantup.com/precise64.box.

Create folder adf-12_1_3-environment (somewhere on your file system) with a subfolder files.

Open command line, change directory to adf-12_1_3-environment and type

vagrant init

This will create the Vagrantfile that provides the starting point for the environment we are going to provision.

Edit the Vagrantfile to specify the appropriate base box to use (one with 64 bit Ubuntu prepared for VirtualBox as provider) and configure the forwarded posts, allocated memory, the synched folders and the provisioning to be performed into the Virtual Machine using puppet:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

config.vm.box = "precise64"
# this VM is based on the predefined box precise64 that is available from the following URL
# note: the box will be downloaded (330 MB) from that URL if Vagrant cannot not find it locally (in the Vagrant home - by default: HOME/.vagrant.d/boxes))
config.vm.box_url = "http://files.vagrantup.com/precise64.box"
config.vm.hostname = "adf12-1-3.amis.sandbox"

# any network request on the host made to the specified port (8888 or 1521) should be forwarded into the VM and handled there
config.vm.network :forwarded_port, guest: 8080, host: 8888
config.vm.network :forwarded_port, guest: 1521, host: 1521

config.vm.synced_folder "files", "/etc/puppet/files"
config.vm.synced_folder "files", "/vagrant", :mount_options => ["dmode=777","fmode=777"]
# the next line is supported from Vagrant 1.6 onwards; it displays a message on the command line after "vagrant up" has brought up the VM
# config.vm.post_up_message = "Virtual Box is running. You can connect using username vagrant with password vagrant."
config.ssh.forward_agent = true

config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "4096"]
vb.gui = true
vb.name = "JDeveloper 12.1.3 with Oracle Database XE 11gR2 on Ubuntu"
end
end

At this stage you can have a VirtualBox VM created with Ubuntu Linux and initialized:

vagrant up

The following output is produced in the command line terminal:

The VM is created and started.

You can login to it using the user vagrant with password vagrant

The VM environment does not have a graphical desktop. Nor does it have either Oracle Database XE or JDeveloper in it at this point – despite the name of the VM. That is what Puppet will do for us.

The VM does already have folders – such as /vagrant – mapped to the files folder on the host machine.

Visually, the following has taken place:

Install Vagrant and VirtualBox. Create Vagrantfile. Run vagrant up to have Vagrant process the Vagrantfile, download the Precise64 box and interact with VirtualBox to create the VM according to specifications, including a folder mapping from /vagrant in the VM to the files subfolder in the host.

To remove this incomplete VM, simply type

vagrant destroy

and confirm your intention.

Engage Puppet to perform provisioning tasks on the VM

Create folders manifests and modules under adf-12_1_3-environment . These folders will contain the configuration files for Puppet.

Add these lines to the Vagrantfile:

config.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.module_path = "modules"
puppet.manifest_file = "base.pp"
end

They instruct Vagrant to run Puppet from within the VM image – starting with the base.pp manifest file (in the manifests sub-folder) and merging the included classes from [the manifests from] all modules (remote and the local subfolders under the the modules folder).

Create a file called base.pp in the folder adf-12_1_3-environment\manifests. Puppet is engaged by Vagrant because of the config.vm.provision configuration in the Vagrantfile. This configuration refers to these directories for manifests and modules. It also refers to file base.pp (in the manifests directory) as the starting point for the actions to be executed by Puppet.

Add the following content to the base.pp file:

package { "build-essential": ensure => present }
package { "ubuntu-desktop": ensure => present }

group { "oracle":
ensure => present,
}

file { "/home/vagrant/importantFileForSomething.txt":
ensure => present,
source => "/etc/puppet/files/someTestFileToBeCopiedToTheVM.txt",
owner => "vagrant",
require => Package["ubuntu-desktop"],
}

exec { "restart-lightdm":
command => "/usr/bin/apt-get install linux-headers-$(uname -r); /etc/init.d/lightdm restart; /usr/bin/touch /etc/puppet/.lightdm",
creates => "/etc/puppet/.lightdm",
subscribe => Package['ubuntu-desktop'],
}

# apt-get update downloads the package lists from the repositories and "updates" them to get information on the newest versions of packages and their dependencies
# see: for example http://askubuntu.com/questions/222348/what-does-sudo-apt-get-update-do
exec { "apt-update":
command => "/usr/bin/apt-get update"
}
Exec["apt-update"] -> Package <| |>

Here we define a number of resources. One is package {“ubuntu-desktop”} ; through that resource, we ensure that Puppet sets up the graphical desktop in our VM. Another resource creates a Linux group (called oracle). The file resource is configured to copy a file called someTestFileToBeCopiedToTheVM.txt from the shared folder /etc/puppet/files – which maps to the files folder on the local, host file system – to the folder /home/vagrant inside the VM. Create that file as a simple text file in the files folder – so when we run Vagrant again, we will see its result.

Now run again the command

vagrant up

After the VM is created, Vagrant passes control to Puppet to provision the additional elements inside the VM. Notice how two additional shared folders are created by Vagrant to accommodate Puppet in accessing the manifests and modules directories in the host:

Also note how Puppet figures out the order in which to execute the resources – based primarily on the require  attribute that indicates mutual dependencies between resources.

This time, a Virtual Box image is created that has a graphical desktop – as was instructed by the base.pp resources. It takes a lot longer than before (400+ seconds) – as the creation of the graphical desktop is not a simple little task. It contains the Firefox browser and the LibreOffice suite among other tools.

We can check if the file someTestFileToBeCopiedToTheVM.txt was indeed copied to the VM and put in the /home/vagrant folder as importantFileForSomething.txt:

Extending our previous visual overview of what happened with the Puppet contribution, we get the following figure:

The Vagrantfile is extended with a line that engages Puppet from the VM. The modules and manifests folders are created with the base.pp file in the manifests folder. This file instructs Puppet to install the Ubuntu desktop and copy a file. Note that Vagrant will automatically add folder mappings for the modules and manifests folders.

Engage Puppet to perform the installation of Oracle Database XE and JDeveloper

Time for some even heavier lifting. Our objective is to install two pieces of Oracle software in the VM: Oracle Database XE 11gR2 and JDeveloper 12.1.3. We need the installation files for that and we need to configure Puppet to perform the installation. We will create to Puppet modules for this – oracle_db and oracle_jdev.

Create a directory files under adf-12_1_3-environment and copy the downloaded files jdev_suite_121300_linux64.bin and oracle-xe-11.2.0-1.0.x86_64.rpm.zip to this directory. This directory is available from within the VM through the synched_folder definitions in the Vagrantfile.

base.pp will soon include several classes from two modules: oracle_db (for the XE installation) and oracle_jdev (for the JDeveloper installation). It also includes a number of [Puppet] resources of its own – entries that will prompt Puppet to inspection and possibly action to ensure the target environment is or will become as specified in the resource definition.

Puppet configuration for the installation of Oracle Database XE 11gR2

The installation of Oracle Database XE 11gR2 using Puppet has been described and realized by several authors, including Michael Medin and Matthew Baldwin (https://github.com/matthewbaldwin/vagrant-xe11g). I have based my scripts on those published by Michael, especially because he also went on to have Puppet provision JDeveloper (12.1.2 in his case).

I have made a few fairly small changes to Michael’s scripts. One thing is the teardown class that I added to remove from the VM the intermediate files used during the install process (to free up disk space).

For the installation of Oracle Database XE, we work with a module called oracle_db. For this module, a directory with the name of the module should be created. Inside this folder are subfolders files, manifests and templates:

Folder manifests contains file init.pp – the file that defines the classes and the resources used for the installation of the Oracle Database XE. This file defines five classes – server, swap, xe, hr_schema and teardown. These classes are supported by several files in the module subfolders files and templates. In the former are files that are used literally in the VM; in the latter are templates that [may] contain references to Puppet variables; these variables are dynamically resolved into the actual values before the contents of the template is used to create a file inside the VM.

and templates:

In this latter template, the password to be used for the HR schema is defined through a variable reference: <%= @hrPassword %>. The reference @hrPassword indicates the $hrPassword variable that is defined in the init.pp file in the oracle_db module:

class oracle_db::config {

$group = "dba"
$hrPassword = "hr"
$sysPassword = "oracle"
}

Class server paves the way for the installation performed by class xe. In server, all Linux dependencies are prepared as is the file system. Class swap prepares the swapfile. Finally, class xe does the actual installation. It unzips the downloaded installation file oracle-xe-11.2.0-1.0.x86_64.rpm.zip (this creates the Disk1 subfolder in the home directory for user vagrant), turns the RPM (not supported on Ubuntu) into a deb file (using alien) and then installs the software package for Oracle Database XE based on that deb file. Then, the resource configure xe can do the real installation – using the response file /tmp/xe.rsp, created from the xe.rsp file in the files directory of module oracle_db.

Class hr_schema uses SQLPLUS to unlock the HR database schema and to set the password for this schema to hr. Note that in the original setup by Michael Medin, this class was part of the oracle_jdev module.

Class teardown – my addition to the work from Michael – removes the /home/vagrant/Disk1 directory when the installation is done (resource “configure xe”), deletes the .deb file created by the “alien xe” resource and removes the .zip file.

The classes in the oracle_db module are now to be included in the main manifest file base.pp in order to do actually be engaged. This is done with the following include lines:

include oracle_db::server
include oracle_db::swap
include oracle_db::xe
include oracle_db::hr_schema
include oracle_db::teardown

Note: class hr_schema inherits from class config. Class config does not have to be explicitly included in base.pp to still be available & accessible.

Three additional resources are added to base.pp to create/configure user oracle, set the password for user oracle and create the home directory for user oracle. Note how the creation of the user is made to depend on the resource Service[“oracle-xe”]. That is a resource defined in class oracle_db::xe – and this is a trick to force the Oracle Installer to create the user oracle with all the required attributes. The user resource will further append to this user.

Once Vagrant is done and Puppet has also completed its provisioning work,

you can start the VM, logon as vagrant, open the Firefox browser and type the URL localhost:8080/apex into the location bar. This should bring up the login page for Application Express (APEX) 4.0:

Note: because of the port forwarding that was specified for the Virtual Machine in the Vagrantfile, you can also access APEX from the host. When you enter http://127.0.0.1:8888/apex in the address bar of a browser running on the host, you will get the same result as in the browser running inside the VM. Note that in Vagrantfile we mapped port 8888 to 8080.

The visual description of the provisioning process:

The Puppet module oracle_db is introduced, its classes included from base.pp. The Oracle Database XE installation file was downloaded from OTN and copied to the files subfolder. Puppet processes the new classes, causing the Oracle Database XE 11gR2 software to be installed.

Puppet configuration for the installation of Oracle JDeveloper 12.1.3

The installation of Oracle JDeveloper 12.1.3 using Puppet is an extension of the work by Michael Medin on JDeveloper 12.1.2. I have taken Michael’s scripts and adapted them for JDeveloper 12.1.3 (a very minor change to be exact).

Create folder modules/oracle_jdev (for module oracle_jdev) with child folders files, manifests and templates as shown:

Folder manifests contains the init.pp that describes the Puppet resources that specify the final state of the VM once JDeveloper 12.1.3 is installed. Remember that earlier on we already copied the JDeveloper installer file (jdev_suite_121300_linux64.bin) to folder adf-12_1_3-environment/files. This file is obviously going to play a role now when the actual installation of JDeveloper takes place.

Here is the contents of the init.pp file – largely taken from Michael Medin’s example:

class oracle_jdev::config {
$group = "dba"
$mdwHome = "/u01/app/oracle/product/12.1.3/jdeveloper"
$oraInventory = "/u01/app/oracle/oraInventory"
$hrPassword = "hr"
$sysPassword = "oracle"
}

class oracle_jdev::install inherits oracle_jdev::config {

include oracle_jdev::config

file { "silent_jdeveloper.xml":
path => "/tmp/silent.xml",
ensure => present,
replace => 'yes',
content => template("oracle_jdev/silent_jdeveloper_1213.xml.erb"),
}

file { "/etc/oraInst.loc":
ensure => present,
content => template("oracle_jdev/oraInst.loc.erb"),
group => "dba",
mode => 0664,
require => Service["oracle-xe"],
}
file { "/usr/share/applications/jdeveloper.desktop":
ensure => present,
content => template("oracle_jdev/jdeveloper.desktop.erb"),
require => Package["ubuntu-desktop"],
}
file { "/usr/share/pixmaps/jdeveloper.png":
ensure => present,
source => "puppet:///modules/oracle_jdev/jdeveloper.png",
}
file { ["/u01/app/oracle/product"]:
ensure => directory,
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
file { ["/u01/app/oracle/product/12.1.3", "/u01/app/oracle/product/12.1.3/jdeveloper"]:
ensure => directory,
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}

exec { "installjdev":
command => "/etc/puppet/files/jdev_suite_121300_linux64.bin -silent -responseFile /tmp/silent.xml -invPtrLoc /etc/oraInst.loc -ignoreSysPrereqs",
user => "oracle",
require => [File["/etc/oraInst.loc"], File["/u01/app/oracle/product/12.1.3/jdeveloper"]],
creates => "/u01/app/oracle/product/12.1.3/jdeveloper/jdeveloper/",
timeout => 0,
}

exec { "change_directory_permissions":
command => "/bin/chmod -R 777 /u01/app/oracle/product/12.1.3",
user => "oracle",
require => Exec["installjdev"],
timeout => 0,
}

}

class oracle_jdev::connections inherits oracle_jdev::config {

include oracle_jdev::config

file { ["/u01/app/oracle/.jdeveloper",
"/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008",
"/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008/o.jdeveloper.rescat2.model",
"/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008/o.jdeveloper.rescat2.model/connections"]:
ensure => directory,
owner => "oracle",
group => "dba",
require => [Service["oracle-xe"],Exec["installjdev"], Exec["change_directory_permissions"]],
}
file { "/home/vagrant/.jdeveloper/system12.1.3.0.41.140521.1008/o.jdeveloper.rescat2.model/connections/connections.xml":
ensure => present,
content => template("oracle_jdev/connections.xml.erb"),
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
}

Some folders and file name were renamed to better reflect the 12.1.3 release as compared to the 12.1.2 that the original file supported. A new logo (jdeveloper.png) was created for JDeveloper 12.1.3 and copied to the files directory in module oracle_jdev. Note how this image is copied into the VM and how it is referenced from the Desktop item that is created using template jdeveloper.desktop.erb in the templates directory for module oracle_jdev.

The crucial resource of course is installjdev that will perform the actual installation. It runs file jdev_suite_121300_linux64.bin – that is available inside the VM from the shared folder /etc/puppet/files. It feeds a response file to the installer (/tmp/silent.xml) that was created from the local template silent_jdeveloper_1213.xml.erb in an earlier file resource. Note that because the installer is ran from a shared folder, it is not actually created in the VM anywhere and therefore does not have to be removed after the installation.

I had some issues with running JDeveloper as user vagrant (because of the directory privileges as set by the Oracle Installer – all assigned to user oracle) and with running JDeveloper as user oracle because of problems with the X11 Windows Server (user oracle could not connect to the GUI). My somewhat crude but effective solution was to simply open up the directories created for the installation of JDeveloper, using the change_directory_permissions resource type. (it is not going to win me any awards, but for such as a simple R&D VM I think I can get away with it).

To ensure that the module oracle_jdev is actually activated, the relevant class(es) have to be included in the main manifest file. Edit manifests/base.pp and add this line:

include oracle_jdev::install

This is all it takes to bring in all the resources inside the install class in the oracle_jdev module.

The console log reports on the JDeveloper installation actions performed by Puppet:

Visually, the entire provisioning process is described in the next figure:

The Puppet module oracle_jdev has been added and included from base.pp. The Linux installer for JDeveloper 12.1.3 was downloaded from OTN and copied to the files subfolder. Puppet processes the resources from the new module, causing JDeveloper 12.1.3 to be installed.

The result from all this activity

After putting all the folders and scripts together, we can give Vagrant one final swing and have it stamp out our VM image. It runs for approximately 900 seconds in my case (15 minutes) and creates the VM, installs Oracle Database XE (cleans up after itself) and installs JDeveloper 12.1.3.

Log in to the VM as vagrant/vagrant.

To run JDeveloper, click on the top icon on the desktop and type jdev as search string. The JDeveloper icon appears. Click it and JDeveloper is started.

The launch image is shown:

You have to reply to familiar dialogs:

and finally JDeveloper’s IDE appears.

Bonus: Creation of sample database schema

In order to be able to quickly create a sample application, it is useful to have some sample data available. As part of the Puppet actions that provision the platform in our VM image, it is little trouble to also have one or more SQL scripts executed against the Oracle Database XE 11gR2 that is installed in the earlier stages of the process. I have created a simple Puppet module with a single manifest file and three SQL files to create a sample schema – in this case with data from the recent World Cup Football.

A new module is created simply by  creating a new folder in the modules folder:

This new folder oracle_amis_sample contains two sub-folders: files and manifests. Folder files contains the SQL scripts we will copy into the VM image:

sys-ddl.sql is executed as sys and creates a new user WC with some system privileges. Files ddl.sql and dml.sql are executed by this new user WC and create objects – such as tables – and data.

The manifest file init.pp in the oracle_amis_sample/manifests folder contains the Puppet resources that describe the transfer and execution of these files. The file defines a class oracle-amis-sample that will be included from the main manifest file: base.pp. The class contains three entries based on the file resource type; these copy files from the files folder in the [local] Puppet module definition to the /u01/app/oracle/scripts folder inside the Virtual Machine. Three other entries are of resource type exec and use SQLPLUS inside the VM to execute a SQL script. Note that the require attribute has been specified to ensure the SQL scripts are executed in the proper order: sys-ddl first, then ddl and finally dml.

class oracle_amis_sample::install {

file { "/u01/app/oracle/scripts/sys-ddl.sql":
ensure => present,
source => "puppet:///modules/oracle_amis_sample/sys-ddl.sql",
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
file { "/u01/app/oracle/scripts/ddl.sql":
ensure => present,
source => "puppet:///modules/oracle_amis_sample/ddl.sql",
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
file { "/u01/app/oracle/scripts/dml.sql":
ensure => present,
source => "puppet:///modules/oracle_amis_sample/dml.sql",
owner => "oracle",
group => "dba",
require => Service["oracle-xe"],
}
exec { "create_wc_schema":
command => "/u01/app/oracle/product/11.2.0/xe/bin/sqlplus -S -L \"sys/$sysPassword as sysdba\" @/u01/app/oracle/scripts/sys-ddl.sql",
user => "oracle",
logoutput => true,
environment => ["ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe", "ORACLE_SID=XE", "ORACLE_BASE=/u01/app/oracle"],
require => [File["/u01/app/oracle/scripts/sys-ddl.sql"], Service["oracle-xe"]],
}
exec { "ddl_in_wc_schema":
command => "/u01/app/oracle/product/11.2.0/xe/bin/sqlplus -S -L \"wc/wc \" @/u01/app/oracle/scripts/ddl.sql",
user => "oracle",
logoutput => true,
environment => ["ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe", "ORACLE_SID=XE", "ORACLE_BASE=/u01/app/oracle"],
require => [Exec["create_wc_schema"]],
}
exec { "dml_in_wc_schema":
command => "/u01/app/oracle/product/11.2.0/xe/bin/sqlplus -S -L \"wc/wc \" @/u01/app/oracle/scripts/dml.sql",
user => "oracle",
logoutput => true,
environment => ["ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe", "ORACLE_SID=XE", "ORACLE_BASE=/u01/app/oracle"],
require => [Exec["ddl_in_wc_schema"]],
}

}

Note: the reference puppet:///modules/oracle_amis_sample/ddl.sql refers to the ddl.sql file in the files child folder under the oracle_amis_sample module. This is by convention: puppet:/// references are resolved against the files subdirectory under the specific module folder.

The base.pp is extended ever so slightly to leverage the new module. All it takes for the oracle-amis-sample module to be included in the provisioning process is the following line:

include oracle_amis_sample::install

Puppet will scan the modules directory for subfolders that contain modules. It will scan the manifests folder inside each module for the definitions of classes and resources. There it finds the oracle_amis_sample::install class defined in the init.pp file in the oracle_amis_sample module. This class is added to the catalog through the include command in base.pp. That is enough to make the resources in oracle_amis_sample/manifests/init.pp be realized.

If we now run

vagrant destroy

followed by

vagrant up

a new VM will be created that has the sample WC schema installed with tables and data in it.

When the VM is created and initialized, login as vagrant and run JDeveloper again – as described above. One thing you may want to do now: leverage these sample objects and data:

Show the Resources window (using the menu entry under Windows) and add a new IDE Connection of type Database:

Configure the database connection – easy enough with username and password equal to wc and the default values for Driver, Hostname and SID equal to the ones we need. Press Test Connection to enjoy the success message. Then press OK to close the dialog.

In the Connections Navigator, you can verify which database objects have been created in the final stages of the provisioning actions (a few tables and one user defined type):

The final visual overview of the entire provisioning process:

One more Puppet module was introduced: oracle_amis_sample. The files folder for this module contains the SQL scripts that Puppet will execute inside the VM against the Oracle Database XE 11gR2 instance.

Resources

The GitHub repository with the sources described in this article: https://github.com/lucasjellema/adf-12-1-3-vm.

Getting started with Puppet – on line tutorial

Getting started with Vagrant – on line tutorial

Download and install Vagrant

Download and install/configure Puppet

Download and install Oracle VirtualBox

Download Oracle Database 11gR2 XE

Download Oracle JDeveloper 12.1.3 for Linux 64 bit

Blog article by the Puppet Master Edwin Biemond, introducing Vagrant (and Packer) in combination with Oracle Virtual Box: http://biemond.blogspot.nl/2013/11/creating-your-own-virtualbox.html

Blog article on Java Mon Amour on using the path variable with Exec resource type (to refer to /bin directory): http://www.javamonamour.org/2013/10/puppet-exec-always-requires-path.html

Blog article by Andreas Koop: Setup WebLogic 12c environment with Vagrant and Puppet – with a great graphic depicting the provisioning of a WebLogic 12c VM:

Blog article on downloading sources from Git by a Puppet action from within the VM – http://livecipher.blogspot.com.au/2013/01/deploy-code-from-git-using-puppet.html

Documentation on VBoxManage – listing all properties that can be passed to modify the VM (and that can be set in Vagrant files using vb.customize) : https://www.virtualbox.org/manual/ch08.html

Vagrant Base Box for Oracle Enterprise Linux 6.5 – https://github.com/terrywang/vagrantboxes/blob/master/oraclelinux-6-x86_64.md