I think what you are looking for is an Open Source project that can take inputs from both Amazon CloudWatch and Google StackDriver; there isn't a huge amount out there at the moment, but I will detail what I know.
I have made the assumption that you know how to import your application telemetry into the solutions below.
Open source solutions ...
Note: I'm not a GCE user yet, the answer is based solely on documentation.
You could be Viewing Audit Logs in the Google Cloud Console, more specifically the Admin Activity logs:
Admin Activity logs contain log entries for API calls or other
administrative actions that modify the configuration or metadata of
resources. For example, the logs record ...
I don't know much about Redis/ElasticSearch, but GCS is not really a database-like solution, it is closer to a file storage solution.
If you're looking for database-like storage Google Cloud offers:
If you expect a modest app traffic or alternating high/low traffic it might be more cost-effective (and ...
It seems that my cluster is capped at 3% of maximum utilization, if I
read the units correctly. This makes no sense at all, why isn't it
capable of reaching 100% ?
Why do you think it does make no sense at all?
I ran a few tests that created quite a few pods
What is a few tests?
(each pod running basically an hello world script)
What does this ...
You can't add deny rules to GC firewall. The default policy is Deny. You can only add allow rules - allow everything you need and let everything else get rejected.
Since the ports you need to block are allowed by default, you simply need to remove them. Check the name of the default rule:
gcloud compute firewall-rules list [NAME …] [--regexp=REGEXP, -r ...
We had the similar requirement as there needs to be a set of data cached in a server for serving the application (fast processing) and also by end of the day, we would need to sync the data from the cache server to the origin server.
In the longer run, I would suggest to go for Redis as you can have Redis as an intermediate database (caching) and it will ...
Thank you to the comment from user54 for the answer.
Both of my pasted wget URLs work as long as I'm using the correct value for password. In this case, I needed to use my user's API Token as described in the answer to another question:
Not sure if you sorted this out, but I had to do something similar to get who started the instance so I can badger them into stopping the instance if they are not using it. I put together a Logging query:
resource.type = gce_instance AND (jsonPayload.event_subtype = compute.instances.start OR jsonPayload.event_subtype = compute.instances.insert ) AND ...
If you cordon and drain the nodepool before deleting it, then you can avoid downtime. I use the following script (shamelessly taken from the lazyweb elsewhere and adapted to my needs):
oldnodes=$(k get no --selector='cloud.google.com/gke-nodepool='$oldpool -o json | jq .items.metadata.name -r | xargs)
kubectl cordon --selector='cloud....
You can find the IP addresses of the Travis build machines here. If you add the IP addresses of the Travis infrastructure you use to your whitelisted IPs in Cloud SQL it should work. Keep in mind these IP addresses can change in the future though.
Yes, it is possible to split the incoming traffic between several GAE app/service versions based on the IP address from which the requests originate. From Splitting traffic across multiple versions:
When you have specified two or more versions for splitting, you must
choose whether to split traffic by using either an IP address or HTTP
cookie. It's ...
Try to use only n1-standard-1 nodes and let the autoscaler do it's magic.
If you can accept some downtime (and eventually some failures of the CI/CD jobs that should be fixed when you retry) you can use preemptible nodes.
Migrate stateless apps to Cloud Run.
Follow this guide to reduce resource consumption on your cluster.
Given that you mentioned rarely using some k8s resources, you could explore some alternatives:
With gcloud SDK you could create scripts to be executed for the periods you want to reduce GKE nodes (even to zero) during periods you're not using it
With Google Cloud Functions (GCF) you can create some python/Node.js/Go script to access GKE APIs and also ...
You seem to be confused a bit about how Firestore stores data and what Google is suggesting you do.
What is the problem? You are backing up a bucket inside other bucket.
This is not correct. Firestore stores its data inside some sort of mostly opaque database format. If you are copying this out to a GCS bucket, that really is an export into a different ...
TombstonedTaskError is raised if you're attempting to enqueue a named task using a name that has been used recently, see What is TombstonedTaskError from App Engine's Task Queue?.
The duration of the de-duplication logic has been documented since that answer was posted. From Naming a task (emphasis mine):
When you create a new task, App Engine assigns ...
The easiest approach does appear to be to use gcloud, as trying to get a kubeconfig without it proved tricky.
Fortunately, gcloud, kubectl and helm are available as a single docker image kiwigrid/gcloud-kubectl-helm. For example:
docker run -it --rm --volume ./gcp-key-file.json:/data/gcp-key-file.json:ro kiwigrid/gcloud-kubectl-helm:2.11.0-224.0.0 bash
I found the solution.
As build artifact you need to publish, firebase.json, .firebaserc and whole functions folder including package.json (without node_modules)
Then in release using sudo firebase deploy --token $(firebase-token) --project $(firebase-project) --only functions --force
I don’t know of a specific tool but I have setup a lot of webhook handlers on OKD kubernetes to do git driven updates to kubernetes. All the scripts are on GitHub as OCD. The tools I used are:
adnanh/webook a go binary that you configure to catch git webhooks and run scripts. Here is my hooks.json config to match GitHub release events and run a build script ...
As far as I'm aware, there is no universal standard amongst cloud providers. One reason for this is because most cloud providers like to abstract how their backend infrastructure, that their instances run on, is managed. How your instance is ran could change minute by minute depending on the cloud provider. The user doesn't care as long as they are getting ...
I think you can do this by Nodeselector. Firstly add a label for node selector in your daemonset config. Then label your nodes with the attached label. Now if you can set the autoscaling thresholds, it will be deployed on that node automatically on nodes that matches the label. Maybe you can tweak somehow to attach a label to your node when it is added to ...
1). Inside the node pool(lets call it old_node_pool ) that you want to delete, First Cordon all the nodes one after the other.
kubectl cordon <name_of_node_1>
kubectl cordon <name_of_node_2>
2). Drain all the nodes of the old_node_pool.
kubectl drain <name_of_node_1>
kubectl drain <name_of_node_2>
We use AWS's EC2 Plugin to spin up spot instances in AWS for our Jenkins master based on a single AMI, exactly as you describe, so Jenkins does support this behavior.
From a quick bit of searching Google Cloud seems to offer a similar solution;
Spotinst’s Jenkins Plugin helps you to do more with your Jenkins setup by allowing you to automatically ...
It's not currently possible to list all the accessible buckets across all cloud projects, neither in the developer console browser nor via the gsutil command. Both of them only display buckets for one project at a time.
But if you specify a particular project (or stick with the one selected by default) you can list the accessible buckets inside that project ...
The service account needs permissions to the storage segment where the containers will be pushed. To fix this
Log in to the Google Cloud Platform console
Go to the Storage section
Tick the corresponding storage segment and click Show information panel button in the top-right corner.
Add the storage object administration permission to your service account.
I looked for that too but I don't think you can as these are the ports used by Google to do LB:
HTTP requests can be load balanced based on port 80 or port 8080. HTTPS requests can be load balanced on port 443.
TCP Proxy Load Balancing supports the following ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 5222
From: GCP HTTP(S) LB ...