I want to launch a instance with two vNic card . On one vnic i want use for private network and other vNic use for public network, How we can do that in openstack ?
you need to boot the image with twice the --nic net-id= argument as in the example bellow:
nova boot --image cirros-0.3.3-x86_64 --flavor tiny_ram_small_disk --nic net-id=b7ab2080-a71a-44f6-9f66-fde526bb73d3 --nic net-id=120a6fde-7e2d-4856-90ee-5609a5f3035f --security-group default --key-name bob-key CIRROSone
here is the result
root#columbo:~# nova list
+--------------------------------------+-----------+---------+------------+-------------+-----------------------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-----------+---------+------------+-------------+-----------------------------------------------+
| d75ef5b3-060d-4ec0-9ddf-a3685a7f1199 | CIRROSone | ACTIVE | - | Running | SecondVlan=5.5.5.4; SERVER_VLAN_1=10.255.1.16 |
+--------------------------------------+-----------+---------+------------+-------------+-----------------------------------------------+
Related
I have created EKS cluster using terraform-aws-modules/vpc/aws with Terraform, I use one VPC with 3 private subnets on each AZs in Frankfurt. I've created two services (tomcat and psql) and deployment which are exposed via LoadBalancer and accessible via internet. It looks fine so far.
but the problem is that it's only one environment (DEV). I would like to create multiple environments like stage,test and more inside one VPC and inside one cluster, how to do it using terraform? should I create new files per environment? It would not make sense but nothing comes to my mind... I was considering also workspaces but the problem is that new workspace requires new state - it means that I need to create new VPC with new cluster per one workspace! maybe I should divide my terraform files to have something like "general" workspace and there would be a configuration to VPC and cluster, and create new workspaces for each of the environments? do you have any ideas or better solutions?
VPC - 172.26.0.0/16
+----------------------+----------------------------------+
| |
| |
| KUBERNETES CLUSTER |
| +-------------------------------------------------+ |
| | | |
| | | |
| | | |
| | +------------------+ +-----------------+ | |
| | | | | | | |
| | | TEST ENV | | DEV ENV | | |
| | | +------+ +-----+ | | +-----+ +-----+ | | |
| | | |tomcat| |psql | | | |tomcat |psql | | | |
| | | +------+ +-----+ | | +-----+ +-----+ | | |
| | | | | | | |
| | +------------------+ +-----------------+ | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +-------------------------------------------------+ |
| |
+---------------------------------------------------------+
It is possible to create multiple environments in a single K8s cluster. You could use namespace for this. To access the different environments from outside the cluster, you can use a different domain name for each environment.
For example dev.abc.com to access the development environment and test.abc.com to access the test environment.
You can "separate the vpc" in its own state file. And then have a workspace for each EKS cluster. For the EKS you can pull the VPC info one of two ways, either from AWS data source by tag or from the state file.
Your tree structure would look something like this:
├── vpc
│ ├── main.tf
│ └── outputs.tf
└── eks
└── main.tf
Add the following to the backend settings in vpc/main.tf:
terraform {
backend "s3" {
...
key = "vpc/terraform.tfstate"
workspace_key_prefix = "vpc"
...
}
}
and eks/main.tf:
terraform {
backend "s3" {
...
key = "eks/terraform.tfstate"
workspace_key_prefix = "eks"
...
}
}
Passing the VPC to the EKS section:
Option 1 (pull from aws data source by name, ref https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/vpc):
data "aws_vpc" "selected" {
filter {
...
}
}
Option 2 (pull from state file):
data "terraform_remote_state" "vpc" {
backend = "s3"
config = {
...
key = "vpc/terraform.tfstate"
workspace_key_prefix = "vpc"
...
}
}
It's not a good practice to manage your applications inside terraform, you can use terraform just to create your cluster (infra) EC2, EKS, VPC.... but what inside the cluster, you can use helm/kubectl.... to manage your pods, for example you can have two repositories, one for terraform iac and the other for projects, then you can manage your environments ( dev, staging, prod...) by namespaces...
I've configured SQL second gen. instance and App Engine application (Python 2.7) in one project. I've made necessary settings according to that page.
app.yaml
runtime: python27
api_version: 1
threadsafe: true
env_variables:
CLOUDSQL_CONNECTION_NAME: coral-heuristic-215610:us-central1:db-basic-1
CLOUDSQL_USER: root
CLOUDSQL_PASSWORD: xxxxxxxxx
beta_settings:
cloud_sql_instances: coral-heuristic-215610:us-central1:db-basic-1
libraries:
- name: lxml
version: latest
- name: MySQLdb
version: latest
handlers:
- url: /main
script: main.app
Now as I try to connect from the app (inside Cloud Shell), the error:
OperationalError: (2002, 'Can\'t connect to local MySQL server through socket \'/var/run/mysqld/mysqld.sock\' (2 "No such file or directory")')
Direct connection works:
$ gcloud sql connect db-basic-1 --user=root
was successful...
MySQL [correction_dict]> SHOW PROCESSLIST;
+--------+------+----------------------+-----------------+---------+------+----------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+------+----------------------+-----------------+---------+------+----------+------------------+
| 9 | root | localhost | NULL | Sleep | 4 | | NULL |
| 10 | root | localhost | NULL | Sleep | 4 | | NULL |
| 112306 | root | 35.204.173.246:59210 | correction_dict | Query | 0 | starting | SHOW PROCESSLIST |
| 112357 | root | localhost | NULL | Sleep | 4 | | NULL |
| 112368 | root | localhost | NULL | Sleep | 0 | | NULL |
+--------+------+----------------------+-----------------+---------+------+----------+------------------+
I've authorized IP to connect to the Cloud SQL instance:
Any hints, help?
Google AppEngine Standard provides a unix socket at /cloudsql/[INSTANCE_CONNECTION_NAME] that automatically connects you to your CloudSQL instance. All you need to do is connect to it at that address. For the MySQLDb library, that looks like this:
db = MySQLdb.connect(
unix_socket=cloudsql_unix_socket,
user=CLOUDSQL_USER,
passwd=CLOUDSQL_PASSWORD)
(If you are running AppEngine Flexible, connecting is different and can be found here)
As far as I Know Amazon RDS Supports Stopping and Starting of Database Instances.
I am running the instance from a Mac OS Sierra
I want to start a DB instance using the AWS Command Line Interface (following this tutorial: http://docs.aws.amazon.com/cli/latest/reference/rds/start-db-instance.html)
But somehow I got an error:
MacBook-Pro-de-lopes:~ lopes$ aws rds start-db-instance lopesdbtest
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:
aws help
aws <command> help
aws <command> <subcommand> help
aws: error: argument operation: Invalid choice, valid choices are:
add-source-identifier-to-subscription | add-tags-to-resource
apply-pending-maintenance-action | authorize-db-security-group-ingress
copy-db-cluster-snapshot | copy-db-parameter-group
copy-db-snapshot | copy-option-group
create-db-cluster | create-db-cluster-parameter-group
create-db-cluster-snapshot | create-db-instance
create-db-instance-read-replica | create-db-parameter-group
create-db-security-group | create-db-snapshot
create-db-subnet-group | create-event-subscription
create-option-group | delete-db-cluster
delete-db-cluster-parameter-group | delete-db-cluster-snapshot
delete-db-instance | delete-db-parameter-group
delete-db-security-group | delete-db-snapshot
delete-db-subnet-group | delete-event-subscription
delete-option-group | describe-account-attributes
describe-certificates | describe-db-cluster-parameter-groups
describe-db-cluster-parameters | describe-db-cluster-snapshots
describe-db-clusters | describe-db-engine-versions
describe-db-instances | describe-db-log-files
describe-db-parameter-groups | describe-db-parameters
describe-db-security-groups | describe-db-snapshot-attributes
describe-db-snapshots | describe-db-subnet-groups
describe-engine-default-cluster-parameters | describe-engine-default-parameters
describe-event-categories | describe-event-subscriptions
describe-events | describe-option-group-options
describe-option-groups | describe-orderable-db-instance-options
describe-pending-maintenance-actions | describe-reserved-db-instances
describe-reserved-db-instances-offerings | download-db-log-file-portion
failover-db-cluster | list-tags-for-resource
modify-db-cluster | modify-db-cluster-parameter-group
modify-db-instance | modify-db-parameter-group
modify-db-snapshot-attribute | modify-db-subnet-group
modify-event-subscription | promote-read-replica
purchase-reserved-db-instances-offering | reboot-db-instance
remove-source-identifier-from-subscription | remove-tags-from-resource
reset-db-cluster-parameter-group | reset-db-parameter-group
restore-db-cluster-from-snapshot | restore-db-cluster-to-point-in-time
restore-db-instance-from-db-snapshot | restore-db-instance-to-point-in-time
revoke-db-security-group-ingress | add-option-to-option-group
remove-option-from-option-group | wait
help
Invalid choice: 'start-db-instance', maybe you meant:
* reboot-db-instance
* create-db-instance
You need to update to the latest version of the AWS CLI tool. The version you currently have installed was released before the RDS start/stop feature was available.
It is a new feature (Announced on Jun 1, 2017). You have to upgrade your AWS CLI.
Amazon RDS Supports Stopping and Starting of Database Instances
Finally managed to successfully deploy cloud foundry to AWS.
Mostly following instructions from http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html
Its failing at the validation step that is to get a success response for the following:
curl api.subdomain.domain/info
Of course I have substituted the subdomain and domain appropriately.
I am getting the error:
404 Not Found: Requested route ('api.XX.XXXXX.com') does not exist.
The request is coming till the Cloud foundry router router_z1. And I can see this error in the logs for router_z1.
Here is output of my bosh vms command:
------------------------------------+---------+---------------+--------------+
| Job/index | State | Resource Pool | IPs |
+------------------------------------+---------+---------------+--------------+
| unknown/unknown | running | medium_z1 | 10.10.16.254 |
| unknown/unknown | running | medium_z2 | 10.10.81.4 |
| unknown/unknown | running | small_errand | 10.10.17.1 |
| unknown/unknown | running | small_errand | 10.10.17.0 |
| api_worker_z1/0 | running | small_z1 | 10.10.17.20 |
| api_z1/0 | running | large_z1 | 10.10.17.18 |
| clock_global/0 | running | medium_z1 | 10.10.17.19 |
| etcd_z1/0 | running | medium_z1 | 10.10.16.20 |
| hm9000_z1/0 | running | medium_z1 | 10.10.17.21 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.10.16.34 |
| loggregator_z1/0 | running | medium_z1 | 10.10.16.31 |
| login_z1/0 | running | medium_z1 | 10.10.17.17 |
| nats_z1/0 | running | medium_z1 | 10.10.16.11 |
| router_z1/0 | running | router_z1 | 10.10.16.15 |
| runner_z1/0 | running | runner_z1 | 10.10.17.22 |
| stats_z1/0 | running | small_z1 | 10.10.17.15 |
| uaa_z1/0 | running | medium_z1 | 10.10.17.16 |
+------------------------------------+---------+---------------+--------------+
The only change that I made in the CF deployment manifest was to eliminate instance from zone 2. The reason being AWS default limit for number of instances on EC2 in a particular region is 20.
Any pointers on how to resolve this issue will be appreciated.
Figured out the problem. Couple of issues:
In the CF deployment manifest make sure the system domain property
is <BOSH_VPC_SUBDOMAIN>.<BOSH_VPC_DOMAIN>. That is if you have
reserved cf.example.com for cloud foundry PaaS. Make sure
cf.example.com is what system_domain property in your cloud
foundry deployment manifest refers to. Infact example.com should
not appear in your deployment manifest anywhere without cf..
Through out the deployment manifest it is always cf.example.com
Do not use '#' in any of the passwords within the deployment
manifest. I have logged a bug for this in cf-releases:
https://github.com/cloudfoundry/cf-release/issues/527
I have used bosh-lite to deploy a single node cloudfoundry in my development environment. After deployment, I run the bosh vms, and it returns the vms list:
+------------------------------------+---------+---------------+--------------+
| Job/index | State | Resource Pool | IPs |
+------------------------------------+---------+---------------+--------------+
| api_z1/0 | running | large_z1 | 10.244.0.138 |
| etcd_leader_z1/0 | running | medium_z1 | 10.244.0.38 |
| ha_proxy_z1/0 | running | router_z1 | 10.244.0.34 |
| hm9000_z1/0 | running | medium_z1 | 10.244.0.142 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.244.0.10 |
| loggregator_z1/0 | running | medium_z1 | 10.244.0.14 |
| login_z1/0 | running | medium_z1 | 10.244.0.134 |
| nats_z1/0 | running | medium_z1 | 10.244.0.6 |
| postgres_z1/0 | running | medium_z1 | 10.244.0.30 |
| router_z1/0 | running | router_z1 | 10.244.0.22 |
| runner_z1/0 | running | runner_z1 | 10.244.0.26 |
| uaa_z1/0 | running | medium_z1 | 10.244.0.130 |
+------------------------------------+---------+---------------+--------------+
But when I try to use "cf api https://api.10.244.0.34.xip.io --skip-ssl-validation" to connect the cloudfoundry, it returns an error:
ConnectEx tcp: No connection could be made because the target machine
actively refused it.
The log information is very general (actually this is the exception from CF client which is written in .net), and doesn't provide useful information.
My question is, which VM handles the api command? And, where can I find the detail log in that VM?
api_z1/0 is handling the command. You can get its logs via the BOSH CLI itself: bosh logs api_z1 0 --all.
You probably also need to add the route to your local route table so that traffic to HAProxy container at 10.244.0.24 knows to go through the BOSH-lite VM at 192.168.50.4. Run bin/add-route or bin/add-route.bat from the root of your BOSH-lite repo.