forked from pivotal-cf/docs-pcf-install
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathoffline_installation.html.md.erb
150 lines (122 loc) · 6.3 KB
/
offline_installation.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
---
title: Installing Pivotal Platform in Air-gapped Environments
owner: Ops Manager
---
<% current_page.data.title = "Installing " + vars.product_name + " in Air-gapped Environments" %>
This topic provides an overview of the components and resources needed to install <%= vars.product_name %> in air-gapped environments, including the typical corresponding automation resources.
##<a id="offline-components"></a> Offline Components
To run <%= vars.product_name %> offline, you must obtain resources from the internet and move them into offline components that store and use them. The method you use to move a resource from Pivotal Network or GitHub into an offline environment can vary from setting up a designated proxy to burning a DVD.
The following image displays types of resources and the components you must move them to in your offline environment. It also includes a jumpbox. The jumpbox is a Linux host for running commands such as `bosh`, `uaac`, and `fly`. You could use the Pivotal Operations Manager VM for this purpose.
<%= image_tag("offline-components.png", :class => "no-border") %>
[//]:https://docs.google.com/drawings/d/1SeyhGSoohmRmgxO41WTlWS03NU6iCnz0AGVkuLl2P7A/edit?usp=sharing
The following table provides more detail about resources and the component you must move them to:
<table>
<tr>
<th>Resource</th>
<th>Component</th>
</tr>
<tr>
<td>Pivotal Network products such as tiles, stemcells, BOSH releases, and Ops Manager</td>
<td>S3 and artifact store</td>
</tr>
<tr>
<td>Pipelines and scripts</td>
<td>Git</td>
</tr>
<tr>
<td>Configuration</td>
<td>Git</td>
</tr>
<tr>
<td>Container images</td>
<td>Docker Registry, S3, or artifact store</td>
</tr>
<tr>
<td>Third Party Resources such as NSX-T and OSS BOSH releases</td>
<td>Artifact store</td>
</tr>
<tr>
<td>Backup artifacts</td>
<td>S3</td>
</tr>
</table>
##<a id="architectural-patterns"></a> Architectural Patterns
The following sections describe three architectural patterns for running <%= vars.product_name %> in air-gapped environments. The pattern you use depends on how your environment is set up.
###<a id="pattern-one"></a> Pattern One: Artifact Store with Internet Access
It is common for organizations to deploy an artifact store such as Artifactory or Nexus as a gateway to the Internet. In this configuration, the artifact store is typically configured as a Docker mirror.
This pattern includes an S3 component that is used only for backups of the <%= vars.product_name %> installation.
<%= image_tag("internet-artifact-store.png", :class => "no-border") %>
[//]:https://docs.google.com/drawings/d/14_35uZLsBxCM6ebbj85uqWv1o2QWv00bw52H6H94HX0/edit?usp=sharing
The following table provides an example of how you might handle resources in this scenario:
<table>
<tr>
<th>Resource</th>
<th>Component</th>
</tr>
<tr>
<td>Pivotal Network products such as tiles, stemcells, BOSH releases, and Ops Manager</td>
<td>This architectural pattern presents the challenge of getting Pivotal Network resources from the Internet into the artifact store. For example, Artifactory and Nexus cannot interact directly with Pivotal Network. You could place Pivotal Network resources in an artifact store either through a remote Concourse worker with access to the Internet, by downloading them from the Internet and placing them in the artifact store manually, or some other method.</td>
</tr>
<tr>
<td>Pipelines and scripts</td>
<td>Store in Git. Use manual clone and push. Modify pipelines to use <code>registry_mirror</code>.</td>
</tr>
<tr>
<td>Configuration</td>
<td>Store in Git. Use manual clone and push.</td>
</tr>
<tr>
<td>Container images</td>
<td>Store in the artifact store that you configured as a mirror.</td>
</tr>
<tr>
<td>Third Party Resources such as NSX-T and OSS BOSH releases</td>
<td>Store in a generic artifact store repository.</td>
</tr>
<tr>
<td>Backup artifacts</td>
<td>Store in a S3 blobstore.</td>
</tr>
</table>
###<a id="pattern-two"></a> Pattern Two: Completely Offline
In completely offline environments, you must bring in all resources manually and store them in the available local components.
<%= image_tag("completely-offline.png", :class => "no-border") %>
[//]:https://docs.google.com/drawings/d/1eVQcGOu6U0QFRghkAm4W5JjoWUdXs_dYIuxsMMjmfjU/edit?usp=sharing
In this architectural pattern, you must configure pipelines to watch components for changes and apply updates when available. The following table provides an example of how you might handle resources in this scenario:
<table>
<tr>
<th>Resource</th>
<th>Component</th>
</tr>
<tr>
<td>Pivotal Network products such as tiles, stemcells, BOSH releases, and Ops Manager</td>
<td>Manually upload to Nexus.</td>
</tr>
<tr>
<td>Pipelines and scripts</td>
<td>Modify pipelines to use a local Harbor Docker registry. Manually clone an online environment, bring it to the offline environment on DVD, and push it to offline Git.</td>
</tr>
<tr>
<td>Configuration</td>
<td>Store in your offline Git.</td>
</tr>
<tr>
<td>Container Images</td>
<td>Get from the Internet, transfer to USB, and push to offline Harbor.</td>
</tr>
<tr>
<td>Third Party Resources such as NSX-T and OSS BOSH releases</td>
<td>Store in a generic artifact store repository.</td>
</tr>
<tr>
<td>Backup artifacts</td>
<td>Store in a S3 blobstore.</td>
</tr>
</table>
###<a id="pattern-three"></a> Pattern Three: TLS Intercepting Proxy
This pattern allows Internet access, but only through a proxy that decrypts and rewrites TLS certificates. In general, this resembles an online install, however it requires that you add your corporate certificate to all BOSH-deployed VMs.
<%= image_tag("tls-intercepting-proxy.png", :class => "no-border") %>
[//]:https://docs.google.com/drawings/d/1xDiLcmQdXQunFR03bhegMhQ4zHmuQzX4QHOpMyZkPac/edit?usp=sharing
Some of the challenges in this pattern include the following:
* Any automation that calls to the Internet will fail if it does not have the corporate certificate in its trust store.
* Concourse tasks that do not use resources do not receive updated BOSH root certificates. This means you must configure tasks to ignore TLS errors or update the root certificates as part of the tasks.