← Older revision
Revision as of 22:27, 27 February 2015
Line 9:
Line 9:
* Private IPv4 networking ''security groups'' is allowing VMs to communicate among themselves
* Private IPv4 networking ''security groups'' is allowing VMs to communicate among themselves
* Nothing is exposed to the public ''Floating IPs'', except the bare minimum (e.g. TCP 80, 443 on web servers). Security groups are selectively opening ports to enforce the policy
* Nothing is exposed to the public ''Floating IPs'', except the bare minimum (e.g. TCP 80, 443 on web servers). Security groups are selectively opening ports to enforce the policy
−
* Access to ANY VM is only made through the salt master acting as a ''
'JumpBox'
'', see [[#Accessing_a_VM_using_SSH|Accessing a VM using SSH]]
+
* Access to ANY VM is only made through the salt master acting as a ''
Jump box
'', see [[#Accessing_a_VM_using_SSH|Accessing a VM using SSH]]
* Every VM is booted from a basic Ubuntu 14.04 LTS image. A minimal ''cloud-init'' script installs ''salt-minion'' and makes it poke the ''salt master''.
* Every VM is booted from a basic Ubuntu 14.04 LTS image. A minimal ''cloud-init'' script installs ''salt-minion'' and makes it poke the ''salt master''.
* Each VM can consult their initial ''cloud-init'' script using OpenStack internal API by doing: <code>curl http://169.254.169.254/openstack/2013-10-17/user_data</code>
* Each VM can consult their initial ''cloud-init'' script using OpenStack internal API by doing: <code>curl http://169.254.169.254/openstack/2013-10-17/user_data</code>
Line 51:
Line 51:
== Accessing a VM using SSH ==
== Accessing a VM using SSH ==
−
To work on any VM on WebPlatform architecture, you have to have one of the site operators to add your SSH public key. Once you have access, you’ll be able to jump to the VMs you are granted access through what’s called a
'
''SSH
Jumpbox'
''.
+
To work on any VM on WebPlatform architecture, you have to have one of the site operators to add your SSH public key. Once you have access, you’ll be able to jump to the VMs you are granted access through what’s called a ''SSH
Jump box
''.
One of the common use-case for this setup is to gain access to [[WPD:Infrastructure/architecture/Reports_to_review_status]], or to make some random checks.
One of the common use-case for this setup is to gain access to [[WPD:Infrastructure/architecture/Reports_to_review_status]], or to make some random checks.
The following will explain how you can install on your local machine the configuration you need to connect to the VMs through SSH.
The following will explain how you can install on your local machine the configuration you need to connect to the VMs through SSH.
+
=== How it works ===
=== How it works ===
−
In summary, a ''SSH
Jumpbox
'' is basically a way to refer to a VM within a private network using a publicly available SSH server acting as a proxy.
+
In summary, a ''SSH
Jump box
'' is basically a way to refer to a VM within a private network using a publicly available SSH server acting as a proxy.
To work on a cluster on a given level, you can use the salt master as a SOCKS proxy to view privileged reports such as service health and usage reports.
To work on a cluster on a given level, you can use the salt master as a SOCKS proxy to view privileged reports such as service health and usage reports.
Line 89:
Line 90:
ssh production.wpdn
ssh production.wpdn
−
You can even connect to a VM directly using the salt master as a ''Jump
Box
''
+
You can even connect to a VM directly using the salt master as a ''Jump
box
''
ssh app1.production.wpdn
ssh app1.production.wpdn