1
1
.. _dev-notes :
2
2
3
- Developer Notes (valid for version 1.0.2 )
3
+ Developer Notes (valid for version 1.0.4 )
4
4
=========================================
5
5
6
6
In :ref: `getting-started-poweruser `, we created a virtual environment from
@@ -9,66 +9,77 @@ completely specify your own environment. Knowledge of Ansible is needed, which
9
9
can be gleaned from their excellent documentation at
10
10
http://docs.ansible.com/ansible/.
11
11
12
- Overview: The Build and Run Processes
13
- -------------------------------------
12
+ .. _dev-build-process :
13
+
14
+ Build and Run
15
+ -------------
16
+
17
+ The Build and Run Processes for Virtual Machines
18
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14
19
15
- This graph shows the operations involved in the build and run processes.
20
+ This graph shows the operations involved in the build and run processes for
21
+ :term: `virtual machine `\s .
16
22
17
- .. image :: images/graph .png
23
+ .. image :: images/vm_graph .png
18
24
19
- Lets break this down:
25
+ The run process is simple: the user follows the instructions in
26
+ :ref: `getting-started-user ` to create a virtual machine for themselves. Lets
27
+ break down the build process:
20
28
21
- - Input Environment -> Developer's Virtual Machine: The input environment is a
22
- :term: `virtual environment ` containing only the operating system and few
29
+ - Input Environment Box File -> Initial Virtual Machine: The input environment
30
+ is a :term: `virtual environment ` containing only the operating system and few
23
31
convenience tools. In development, Vagrant and VirtualBox create a
24
32
:term: `virtual machine ` from this environment in the ``create_vm `` role (see
25
33
:ref: `dev-build-process `).
26
34
27
- - Ansible Provisions: Vagrant commands Ansible to provision this machine using
28
- an Ansible playbook.
35
+ - Initial Virtual Machine -> Virtual Machine with Simulation Packages: Vagrant
36
+ commands Ansible to provision this machine using an Ansible playbook.
29
37
30
- - Developer's Virtual Machine -> Output Environment: Vagrant then packages the
31
- virtual machine into a new virtual environment, which can be distributed to
32
- others. Tagged releases are uploaded by administrators to
33
- atlas.hashicorp.com, where they become available to all Vagrant users.
38
+ - Virtual Machine with Simulation Packages -> Output Environment Box File:
39
+ Vagrant then packages the virtual machine into a new virtual environment,
40
+ which can be distributed to others. Tagged releases are uploaded by
41
+ administrators to atlas.hashicorp.com, where they become available to all
42
+ Vagrant users.
34
43
35
- - Output Environment -> User's Virtual Machine: The previous steps are run in
36
- the build phase by a developer as the build process. This step represents the
37
- user following the instructions in :ref: `getting-started-user ` to create a
38
- virtual machine for themselves, which is referred to as the run process.
44
+ The Build and Run Processes for Containers
45
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39
46
40
- The run process performed by the user has been documented in
41
- :ref: `getting-started-user `. Here we introduce the build process, which
42
- represents the other section of this diagram.
47
+ In the same way, this graph shows the operations involved in the build and run
48
+ processes for :term: `container `\s .
43
49
44
- .. _dev-build-process :
50
+ .. image :: images/container_graph.png
51
+
52
+ Again the process of creating and running a container as a user is as simple as
53
+ following the instructions in :ref: `getting-started-user `. The build process is
54
+ also similar; a container template (:term: `image `) is downloaded, a container
55
+ is created and provisioned, and the container is packaged as an image for
56
+ download by all Docker users. The key difference is that Docker pushes the
57
+ image to https://hub.docker.com/ as opposed to Vagrant.
45
58
46
- The Build Process
47
- ~~~~~~~~~~~~~~~~~
59
+ Details
60
+ ~~~~~~~
48
61
49
62
The build (make) process in step 3 in :ref: `getting-started-poweruser ` allowed
50
63
us to create a virtual environment. The Makefile in the software repository can
51
64
build multiple targets. Each target runs Ansible on the ``master.yml ``
52
- playbook, which in turn runs the ``create_vm `` role in the roles
53
- directory. This creates a virtual machine and provisions it with the playbook
54
- passed as a command-line argument in ``Makefile ``, which lives in the jobs
55
- directory. It will also do some post-provisioning tasks using the hookbook,
56
- again passed as a command-line argument. The fundamental difference between the
57
- playbook and the hookbook is that the playbook is run on the guest virtual
58
- machine by vagrant , and the hookbook is run on the host machine. Different
59
- Makefile targets may place different build artefacts in the artefacts
60
- directory.
65
+ playbook, which in turn runs the ``create_vm `` or `` create_container `` role in
66
+ the roles directory. This creates a virtual machine or container and provisions
67
+ it with the playbook passed as a command-line argument in ``Makefile ``, which
68
+ lives in the jobs directory. It will also do some post-provisioning tasks using
69
+ the hookbook, again passed as a command-line argument. The fundamental
70
+ difference between the playbook and the hookbook is that the playbook is run on
71
+ the guest virtual machine by :term: ` Vagrant ` , and the hookbook is run on the
72
+ host machine. Different Makefile targets may place different build artefacts in
73
+ the artefacts directory.
61
74
62
75
Roles add or configure software, playbooks describe the roles that must be
63
76
enacted to provision the machine, hookbooks describe what to do with that
64
77
machine (like creating a :term: `box file `), and jobs are Makefile targets that
65
- produce certain machines.
66
-
67
- To add a new environment, one needs to add a job that follows the pattern of
68
- existing jobs.
78
+ produce certain machines. To add a new environment, one needs to add a job that
79
+ follows the pattern of existing jobs.
69
80
70
81
Where Things Are
71
- ----------------
82
+ ~~~~~~~~~~~~~~~~
72
83
73
84
In order to add jobs, one should edit ``Makefile ``. In order to do that, one
74
85
would need to know where things are, hence the purpose of this section. The
@@ -115,8 +126,8 @@ server. Firstly, we add a target to ``Makefile`` (append the following to the ``
115
126
116
127
# This target builds a virtual hard disk file containing an OOMMF and Fidimag
117
128
# installation.
118
- doc-example:
119
- ansible-playbook master.yml -c local -i localhost, -v -k --extra-vars="vm_name=virtualmicromagnetics-doc-example playbook=provision_virtualmicromagnetics_doc-example.yml hookbook=hook .yml extra_resources_dir=guest_resources/"
129
+ doc-example-vm :
130
+ ansible-playbook master.yml -c local -i localhost, -v -k --extra-vars="type=vm vm_name=virtualmicromagnetics-doc-example playbook=provision_virtualmicromagnetics_doc-example.yml hookbook=hook_vm .yml extra_resources_dir=guest_resources/"
120
131
121
132
Now we need to describe what the state of the machine should be, by writing the
122
133
playbook `jobs/provision_virtualmicromagnetics_doc-examples.yml `::
@@ -199,8 +210,25 @@ now looks like::
199
210
- { role: set_hostname, HOSTNAME: {{ vm_name }} }
200
211
- emacs
201
212
202
- Further Tinkering
203
- ~~~~~~~~~~~~~~~~~
213
+ Can I have a Container Too?
214
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
215
+
216
+ You certainly can, with minimal changes too. Add this target to your Makefile::
217
+
218
+ # This target builds a container image containing an OOMMF and Fidimag
219
+ # installation.
220
+ doc-example-container:
221
+ ansible-playbook master.yml -c local -i localhost, -v -k --extra-vars="type=container container_name=doc-example playbook=provision_virtualmicromagnetics_doc-example.yml hookbook=hook_container.yml extra_resources_dir=guest_resources/"
222
+
223
+ The only differences between this target and the one added previously are:
224
+
225
+ - The value of "type" is now "container", not "vm".
226
+ - The value of "hookbook" is now "hook_container.yml", not "hook_vm.yml".
227
+ - "vm_name=virtualmicromagnetics-doc-example" is now
228
+ "container_name=doc-example".
229
+
230
+ Further Tinkering with the Virtual Machine
231
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
204
232
205
233
We have explored how a new :term: `virtual environment ` can be created, and how
206
234
new software can be added. In this section, we describe how the virtual machine
@@ -240,9 +268,10 @@ Summary and Final Words
240
268
To summarise, :term: `virtual environment `\s are created from an empty Ubuntu
241
269
virtual machine after being provisioned and packaged. This build process allows
242
270
the user to create a Virtual Micromagnetics :term: `virtual machine ` using
243
- Vagrant and VirtualBox. We have also presented how a new environment can be
244
- created, how the software of that environment can be controlled, and how the
245
- virtual machines can be parameterised.
271
+ Vagrant and VirtualBox. A similar approach is used to create :term: `image `\s
272
+ for :term: `Docker ` :term: `containers `\. We have also presented how a new
273
+ environment can be created, how the software of that environment can be
274
+ controlled, and how the virtual machines can be parameterised.
246
275
247
276
Thank you for using Virtual Micromagnetics! If you create roles for your
248
277
favourite software, consider sharing them with the community. You can create a
0 commit comments