I'm working through the example at this URL, but I'm running into the error below. What is the source of that error?
ERROR: (gcloud.run.services.add-iam-policy-binding) NOT_FOUND: Requested entity was not found.
I'm running the script below, but obviously with a different parameter set. I verified in the GUI/Console that the service account was created, the $serviceAccount variable has the correct value, the service exists, and the service name is correct. Also, I'm able to manually add the service account to the service in the invoker role in the GUI/Console.
param(
$cloudRunInvokerServiceAccount = 'some-service-account',
$projectId = 'some-project-id',
$nameOfServiceBeingInvoked = 'some-service'
)
gcloud iam service-accounts create $cloudRunInvokerServiceAccount --display-name $cloudRunInvokerServiceAccount
$serviceAccount = "serviceAccount:$cloudRunInvokerServiceAccount#$projectId.iam.gserviceaccount.com"
gcloud run services add-iam-policy-binding $nameOfServiceBeingInvoked `
--member=$serviceAccount `
--role=roles/run.invoker `
--platform=managed
I also reviewed the docs for good measure.
Also, I ran gcloud run services list and gcloud iam service-accounts list to verify the existence of the services/accounts and their status (enabled).
I have seen this error with old versions of the Google Cloud CLI gcloud.
The solution is to update the Google Cloud SDK and components.
Windows:
Open an elevated Windows Commmand Prompt.
Execute this command and follow the prompts: gcloud components update
Linux:
Execute this command and follow the prompts: sudo gcloud components update
Related
I have gcloud working in power shell:
> gcloud version
Google Cloud SDK 375.0.0
bq 2.0.74
core 2022.02.25
gsutil 5.6
I've been trying to follow these directions to get my Sql Management Studio to connect to a Google SQL service:
https://cloud.google.com/sql/docs/sqlserver/connect-admin-proxy#start-proxy
But I get this error:
PS C:\gcloud_stuff> ./cloud_sql_proxy -instances=<my instance connection>=tcp:1433
2022/03/06 02:02:51 GcloudConfig: error reading config: exit status 1; stderr was:
The system cannot find the path specified.
The system cannot find the path specified.
2022/03/06 02:02:51 google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
Does anyone know how to fix this? (I am new to Google Cloud)
Looks like you don't have a local set of credentials.
You can either run gcloud auth login and try again. Or you can create a service account key and pass it to the proxy with the -credentials_file flag. See the Proxy docs for details.
Is there any difference between a key that I create using the gcloud iam command below vs. going thru the console to create a json key? Each results in a .json file that other than obvious differences in the private_key_id and private_key values are identical. Here are the gcloud commands I am using:
gcloud iam service-accounts create my-sa-name
gcloud projects add-iam-policy-binding my-project-id --member="serviceAccount:my-sa-name#my-project-id.iam.gserviceaccount.com" --role="roles/owner"
gcloud iam service-accounts keys create key.json --iam-account=serviceAccount:my-sa-name#my-project-id.iam.gserviceaccount.com
However, when I try and leverage the one pulled down thru the command line, I get:
google.auth.exceptions.RefreshError: ('invalid_grant: Invalid JWT Signature.', '{"error":"invalid_grant","error_description":"Invalid JWT Signature."}')
Oddly if I go to the console, create a key for the same service account, and put the file that downloads to my computer in place of the one from the CLI, all works fine.
How am I using the key you ask? I'm using the function-frameworks to locally run and debug a cloud function that will access a cloud storage bucket, so my code is using the google.cloud.storage client library (python 3.8). I run the local process with the environment variable GOOGLE_APPLICATION_CREDENTIALS set to the location/filename of the json key file. I know this all works fine b/c of the console-downloaded key working fine.
I have also tried using gcloud auth service-account --key-file=key.json and this also gives me the Invalid JWT Signature error.
Fortunately I'm not blocked b/c I can use the manually-created key, but I would REALLY like to automate every possible step here...
So... can anyone explain this? Seen it, figured it out and know how to fix it?
gcloud iam service-accounts keys create key.json \
--iam-account=my-sa-name#my-project-id.iam.gserviceaccount.com
One way to clarify this is:
ACCOUNT="[[YOUR-ACCOUNT]]"
PROJECT="[[YOUR-PROJECT]]"
EMAIL="${ACCOUNT}#${PROJECT}.iam.gserviceaccount.com"
gcloud iam service-accounts create ${ACCOUNT} \
--project=${PROJECT}
gcloud projects add-iam-policy-binding ${PROJECT} \
--member="serviceAccount:${EMAIL}" \
--role="roles/owner"
gcloud iam service-accounts keys create ${ACCOUNT}.json \
--iam-account=${EMAIL} \
--project=${PROJECT}
I installed gcloud SDK with brew cask install google-cloud-sdk
$ gcloud container clusters get-credentials my-gke-cluster --region europe-west4-c
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials)
Unable to write file [/Users/xxxxx/my-repo]: [Errno 21] Is a directory: '/Users/xxxxx/my-repo'
Now all permissions of the folder and recursive files are restricted to 600 (drw-------). Tried to reinstall gcloud but with no effect on its behavior.
I assume you're using macOS and I'm unfamiliar with it.
The gcloud container clusters get-credentials command should write to a file called ${HOME}/.kube/config.
The error suggests that it's trying to write the credentials to /Users/xxxxx/my-repo and this is determined by the value of ${KUBECONFIG}. Have you changed either ${KUBECONFIG} or your ${HOME} environment variable? You should be able to printf "HOME=${HOME}\nKUBECONFIG=${KUBECONFIG}" to inspect these.
You may be able to choose a different destination by adjust the value of KUBECONFIG. Perhaps set this to /Users/xxxxx and try the command again.
Ultimately, this is some sugar to update the local configuration file. It should be possible to create this manually if needs be. If the above don't work, I can update this answer with more details.
How do I connect to the database on Cloud SQL without having to add my credentials file inside the container?
UPDATE: to connect to Cloud SQL from Cloud Run see the official documentation
Cloud SQL is now supported by the fully managed version of Cloud Run (Cloud Run on GKE users were already able to use Cloud SQL using a private IP)
To get started:
if you do not have one already, create a Cloud SQL instance.
make sure that the Cloud SQL admin API is enabled
deploy a new revision of your Cloud Run service with gcloud alpha and the following flag:
$ gcloud run services update --add-cloudsql-instances [INSTANCE_CONNECTION_NAME]
Where is INSTANCE_CONNECTION_NAME is of the type project:region:instancename.
When you do this, Cloud Run will activate and configure the Cloud SQL proxy for you. You should then connect to it via the /cloudsql/[INSTANCE_CONNECTION_NAME] Unix socket.
CONNECTING FROM CLOUD RUN (fully managed) TO CLOUD SQL USING UNIX DOMAIN SOCKETS (Java)
At this time Cloud Run (fully managed) does not support connecting to
the Cloud SQL instance using TCP. Your code should not try to access the instance
using an IP address such as 127.0.0.1 or 172.17.0.1.
link
1.Install and initialize the Cloud SDK
2.Update components:
gcloud components update
3.Create a new project
gcloud projects create run-to-sql
gcloud config set project run-to-sql
gcloud projects describe run-to-sql
4.Enable billing
gcloud alpha billing projects link run-to-sql --billing-account XXXXXX-XXXXXX-XXXX
5.Set the compute project-info metadata:
gcloud compute project-info describe --project run-to-sql
gcloud compute project-info add-metadata --metadata google-compute-default-region=europe-west2,google-compute-default-zone=europe-west2-b
6.Enable the Cloud SQL Admin API:
gcloud services enable sqladmin.googleapis.com
7.Create a Cloud SQL instance with public Ip
#Create the sql instance in the same region as App Engine Application
gcloud --project=run-to-sql beta sql instances create database-external --region=europe-west2
#Set the password for the "root#%" MySQL user:
gcloud sql users set-password root --host=% --instance database-external --password root
#Create a user
gcloud sql users create user_name --host=% --instance=database-external --password=user_password
#Create a database
gcloud sql databases create user_database --instance=database-external
gcloud sql databases list --instance=database-external
gcloud sql instances list
Cloud Run (fully managed) uses a service account to authorize your
connections to Cloud SQL. This service account must have the correct
IAM permissions to successfully connect. Unless otherwise configured,
the default service account is in the format
PROJECT_NUMBER-compute#developer.gserviceaccount.com.
8.Ensure that the service account for your service has one of the following IAM roles:Cloud SQL Client (preferred)
gcloud iam service-accounts list
gcloud projects add-iam-policy-binding run-to-sql --member serviceAccount:PROJECT_NUMBER-compute#developer.gserviceaccount.com. --role roles/cloudsql.client
9.Clone the java-docs-repository
git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git
cd java-docs-samples/cloud-sql/mysql/servlet/
ls
#Dockerfile pom.xml README.md src
10.Inspect the file that handle the connection to Cloud SQL
cat src/main/java/com/example/cloudsql/ConnectionPoolContextListener.java
11.Containerizing the app and uploading it to Container Registry
gcloud builds submit --tag gcr.io/run-to-sql/run-mysql
12.Deploy the service to Cloud Run
gcloud run deploy run-mysql --image gcr.io/run-to-sql/run-mysql
13.Configure the service for use with Cloud Run
gcloud run services update run-mysql --add-cloudsql-instances run-to-sql:europe-west2:database-external --set-env-vars CLOUD_SQL_CONNECTION_NAME=run-to-sql:europe-west2:database-external DB_USER=user_name,DB_PASS=user_password,DB_NAME=user_database
14.Test it
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://run-mysql-xxxxxxxx-xx.x.run.app
SUCCESS!
I was facing an issue with connecting from a dockerized FastApi application to CloudSQL via private ip. I took the following 3 steps to resolve my issue:
Ensure your application is utilizing the proper database-connection-string.
Sanity check, always do this first. You don't want to spend hours researching a solution without first ruling out a wrong connection string.
When testing (and only when testing): consider logging the db connection string on app init so you can explicitly confirm your connection string is correct.
Provide the Cloud SQL Client role to my cloudrun default service account.
Contains the following permissions:
cloudsql.instances.connect
cloudsql.instances.get
Create a VPC connector within the network of the database (documentation). And assign the VPC connector to the Cloud Run service.
I've been following a tutorial on creating a chatbot with Dialogflow and I've reached the section to do the fulfillment. The Google Cloud SDK got installed but when it comes time to deploy the function I keep getting this error.
https://dialogflow.com/docs/getting-started/basic-fulfillment-conversation
Jasons-MBP-3:~ jason$ sudo gcloud beta functions deploy Goddard --stage-bucket goddard.appspot.com --trigger-http
-2 ['./.git', './.gitignore']
-1 [False, False]
ERROR: gcloud crashed (OSError): [Errno 2] No such file or directory: './Library/Application Support/Google/Chrome/RunningChromeVersion'
If you would like to report this issue, please run the following command:
gcloud feedback
To check gcloud for common problems, please run the following command:
gcloud info --run-diagnostics
I tried sudo and updating the gcloud components but still the same thing. I went to the folder it says doesnt exist and I see the file there but it's an alias. When I click the alias Finder says it can't be opened because th original can't be found. Any suggestions?
So a friend of mine told me that for this section it had to be running in the same directory where the index.js file is. In case anyone else gets stuck!