Most services on the IBM Cloud catalog now support "private endpoints" as described at https://cloud.ibm.com/docs/account?topic=account-service-endpoints-overview
I'm writing some automation for our application and I'd like to obtain the private endpoint for my database from a simple bash script.
I found that I can create a service key and invoke ibmcloud resource service-key (NAME | ID) to list the contents of that key (which includes the service's public endpoint).
Unfortunately, I can't seem to find any command for listing the corresponding private endpoint.
In this particular case I am using the databases-for-postgresql service, but I was hoping for a general way to do this that will work across service types.
I can get the private endpoint information from the UI, so I know the service instance has one.
If I can't get the private endpoint from an existing command, can I piggy-back on the cli's session to invoke a curl command without messing with IAM?
For example, to invoke the curl command mentioned at the bottom of https://www.ibm.com/cloud/blog/introducing-private-service-endpoints-in-ibm-cloud-databases
curl -sS -XPOST "https://api.us-south.databases.cloud.ibm.com/v4/ibm/deployments/<deployment CRN/users/admin/connections/private" \
-H "Authorization: Bearer <IBM API TOKEN>"
The IBM Cloud CLI Cloud Databases plug-in provides this capability. Details about the deployment-connections command can be found here: https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-reference#connections
The syntax is roughly: ibmcloud cdb deployment-connections [the-database] -e private
If you have not already installed this plug-in, you can do so with this command: ibmcloud plugin install cdb
Related
I want to trigger the google data fusion instance with the command as follows
POST -H "Authorization: Bearer ${AUTH_TOKEN}" "${CDAP_ENDPOINT}/v3/namespaces/namespace-id/apps/pipeline-name/workflows/DataPipelineWorkflow/start"
but I cant able to figure out one thing that what will be the CDAP_ENDPOINT in this kindly help me out by telling that from where i can find out the cdap_endpoint
Thanks
This is nicely explained in GCP documentation, as you might be able to get Data fusion API endpoint throughout the following command lines, invoking them in cloud shell:
export INSTANCE_ID=your-Data fusion instance-id
export CDAP_ENDPOINT=$(gcloud beta data-fusion instances describe \
--location=us-central1 \
--format="value(apiEndpoint)" \
${INSTANCE_ID})
Using the ibmcloud CLI, how do I specify Suspended billing?
I am trying to create two identical VM instances, the first via the GUI and the second via the ibmcloud CLI.
Classic Infrastructure.
CLI command:
ibmcloud sl vs create -H ibm -D example.com -c 1 -m 2048 -d dal13 -o UBUNTU_18_64 --disk 25 --san
When I compare the two instances in the GUI, they are identical except for hostname, IP addresses and Suspended billing. The are also identical when using the CLI command ibmcloud sl vs detail ID.
The problem I am trying to solve is: instances created with the CLI have Suspending billing as Unavailable. Instances created thru the GUI have Suspended billing as Enabled on Power Off.
This link is the documentation that I am using for creating an instance with the CLI. No mention of Suspended billing options.
I solved this problem, but I am very open to additional information. Please comment if you know the link to any documentation on this matter.
It appears that you must select a preconfigured virtual server instance type called "flavor" to enabled suspended billing. I could not find any clear documentation on this, but I saw this in API calls link.
I found this command which lists the flavors available:
ibmcloud sl vs options
This CLI command creates an instance with suspended billing enabled. Notice the use of the --flavor command line option:
ibmcloud sl vs create -H ibm2 -D example.com --flavor B1_1X2X25 -d dal13 -o UBUNTU_18_64 --san
Cloud foundry provides facility to specify credentials as part of cf bind-service command. I am using this facility to specify custom credentials while binding WIoTP service to an app in Bluemix. As in below anonymized command
cf bind-service demo-app dev-iotf-service -c '{"apiKey":"a-dummyorg-dummy12345","apiToken":"dummyapikey","base_uri":"https://dummyorg.internetofthings.ibmcloud.com:443/api/v0001","http_host":"dummyorg.internetofthings.ibmcloud.com","iotCredentialsIdentifier":"dummyid","mqtt_host":"dummyorg.messaging.internetofthings.ibmcloud.com","mqtt_s_port":8883,"mqtt_u_port":1883,"org":"dummyorg"}'
I have generated service-key using cf create-service-key command.
Invalid configuration provided for -c flag. Please provide a valid
JSON object or path to a file containing a valid JSON object.
What am I doing wrong? Or is it that Bluemix,WIoTP currently doesn't support specifying custom credentials as part of cf bind-service command. I really don't want to go CUPs route as that would need change in quite a few apps which expect WIoTP credentials to be present in iotf-service object.
I can invoke the command exactly as you have specified (apart from substituting my app and service name) using bx client:
bx cf bind-service myapp my-iotf-service -c '{"apiKey":"a-dummyorg-dummy12345","apiToken":"dummyapikey","base_uri":"https://dummyorg.internetofthings.ibmcloud.com:443/api/v0001","http_host":"dummyorg.internetofthings.ibmcloud.com","iotCredentialsIdentifier":"dummyid","mqtt_host":"dummyorg.messaging.internetofthings.ibmcloud.com","mqtt_s_port":8883,"mqtt_u_port":1883,"org":"dummyorg"}'
and it works. Possibly you simply have an old cf client. You should use the bx client as available at https://console.bluemix.net/docs/cli/index.html#downloads
However, IoTP does not support this and so ignores anything sent via this means. The obvious case would be to either create a limited API key or use an API key you have already created as you are attempting. Unfortunately you would need to submit an idea at https://ibmcloud.ideas.aha.io/?category=6343565373323972470 to get it considered.
The Compose documentation describes how a backup can be initiated:
export APIKEY=your_apikey_here
export DEPLOYMENT=your_deployment_id
curl -X POST -H "Authorization: Bearer $APIKEY" -H "Content-Type: application/json" "https://api.compose.io/2016-07/deployments/${DEPLOYMENT}/backups"
I would like to execute this API call against a 'Standard' Compose database running on Bluemix (not Compose Enterprise).
The DEPLOYMENT_ID is available in the VCAP_SERVICES json, but I can't find the APIKEY - where can I find this?
The docs you refer to are specifically for the Compose native API and not for the IBM Cloud (now) Compose API.
The IBM Cloud Compose API arrived in public in November - https://www.ibm.com/blogs/bluemix/2017/11/opening-the-compose-api-on-the-ibm-cloud/.
Consult https://www.compose.com/articles/the-ibm-cloud-compose-api/ for details on how to use it and where to retrieve appropriate IBM Cloud API keys, which IBM Cloud endpoints to use and what Compose API calls are available (Spoiler: Yes, you can do on demand backups from there).
I am trying to use CloudFOundry REST calls to create app, bind service etc instead of using vmc or eclipse plugin. I know we can use vcap-java-client for this but I also wanted to test calling the REST services directly such as by using cUrl utility. Where do I find the REST urls and json structs corresponding to each vmc command ?
The best way for you to see the actual rest calls to the Cloud Controller is executing the vmc commands and add the -t. So for example:
vmc apps -t
So this vmc command will show you a list of your apps and so what you get out of the additional -t is a more verbose information which shows the Cloud Controller service you are calling. In this case it would be /apps
The same command on the bottom will give you the exact output you would get from the above vmc command:
curl -H "Authorization: <Your-Oauth-token>" https://api.cloudfoundry.com/apps
The Authorization token can also be found in the -t generated output. you need to copy the entire Authorization "bearer"
Sudipta,
When you login and run vmc apps -t, you should see the following output:
Getting applications. >>>
REQUEST: GET /apps
REQUEST_HEADERS:
accept : application/json
user-agent : Ruby
authorization : bearer <token>
content-length : 0
The authorization in REQUEST_HEADERS is what you would need to use.