We currently can call eb create to create and deploy our app onto AWS Elastic Beanstalk hosting.
My need is to have the same outcome with no scaling i.e. single instance mode.
What is the command syntax for that?
I try
eb create --help
and find -s --single param to get it single.
Related
We have installed the pg_repack extension in Cloud SQL by following the guide:
https://cloud.google.com/sql/docs/postgres/extensions#pg_repack
The installation of the extension works fine and it shows up in the list of extensions when running \dx.
We then want to invoke the extension, but it is unclear from where this should be done. The docs just say to "run the command":
pg_repack -h <hostname> -d testdb -U csuper1 -k -t t1
We cant find anywhere in our project where this command can be invoked though. Do we have to set up a compute engine instance for this, or is there some other way?
We only use Cloud Run for running our code at the moment and would like to keep things as small/simple as possible.
Our solution: We built a docker image that wrapped pg_repack with http, and then deployed it as a Cloud Run service. This enabled us to invoke pg_repack periodically using the cloud scheduler.
I've very familiar with doing all of this (quite tedious) stuff manually with ECS.
I'm experimenting with Copilot - which is really working - I have one service up really easily, but my solution has multiple services/containers.
How do I now add a second service/container to my cluster?
Short answer: change to your second service's code directory and run copilot init again! If you need to specify a different dockerfile, you can use the --dockerfile flag. If you need to use an existing image, you can use --image with the name of an existing container registry.
Long answer:
Copilot stores metadata in SSM Parameter Store in the account which was used to run copilot app init or copilot init, so as long as you don't change the AWS credentials you're using when you run Copilot, everything should just work when you run copilot init in a new repository.
Some other use cases:
If it's an existing image like redis or postgres and you don't need to customize anything about the actual image or expose it, you can run
copilot init -t Backend\ Service --image redis --port 6379 --name redis
If your service lives in a separate code repository and needs to access the internet, you can cd into that directory and run
copilot init --app $YOUR_APP_NAME --type Load\ Balanced\ Web\ Service --dockerfile ./Dockerfile --port 1234 --name $YOUR_SERVICE_NAME --deploy
So all you need to do is run copilot init --app $YOUR_APP_NAME with the same AWS credentials in a new directory, and you'll be able to set up and deploy your second services.
Copilot also allows you to set up persistent storage associated with a given service by using the copilot storage init command. This specifies a new DynamoDB table or S3 bucket, which will be created when you run copilot svc deploy. It will create one storage addon per environment you deploy the service to, so as not to mix test and production data.
The docs describe that hasura needs the postgres connection string with the HASURA_GRAPHQL_DATABASE_URL env var.
Example:
docker run -d -p 8080:8080 \
-e HASURA_GRAPHQL_DATABASE_URL=postgres://username:password#hostname:port/dbname \
hasura/graphql-engine:latest
It looks like that my problem is that the server instance connection name for google cloud sql looks like PROJECT_ID:REGION:INSTANCE_ID is not TCP
From the cloud run docs (https://cloud.google.com/sql/docs/postgres/connect-run) I got this example:
postgres://<db_user>:<db_pass>#/<db_name>?unix_sock=/cloudsql/<cloud_sql_instance_name>/.s.PGSQL.5432 but it does not seem to work. Ideas?
I'm currently adding the cloud_sql_proxy as a workaround to the container so that I can connect to TCP 127.0.0.1:5432, but I'm looking for a direct connection to google-cloud-sql.
// EDIT Thanks for the comments, beta8 did mostly the trick, but I also missed the set-cloudsql-instances parameter: https://cloud.google.com/sdk/gcloud/reference/beta/run/deploy#--set-cloudsql-instances
My full cloud-run command:
gcloud beta run deploy \
--image gcr.io/<PROJECT_ID>/graphql-server:latest \
--region <CLOUD_RUN_REGION> \
--platform managed \
--set-env-vars HASURA_GRAPHQL_DATABASE_URL="postgres://<DB_USER>:<DB_PASS>#/<DB_NAME>?host=/cloudsql/<PROJECT_ID>:<CLOUD_SQL_REGION>:<INSTANCE_ID>" \
--timeout 900 \
--set-cloudsql-instances <PROJECT_ID>:<CLOUD_SQL_REGION>:<INSTANCE_ID>
As per v1.0.0-beta.8, which has better support for Postgres connection string parameters, I've managed to make the unix connection to work, from Cloud Run to Cloud SQL, without embedding the proxy into the container.
The connection should look something like this:
postgres://<user>:<password>#/<database>?host=/cloudsql/<instance_name>
Notice that the client will add the suffix /.s.PGSQL.5432 for you.
Make sure you added also the Cloud SQL client permission.
If the Hasura database requires that exact connection string format, you can use it. However, you cannot use Cloud Run's Cloud SQL support. You will need to whitelist the entire Internet so that your Cloud Run instance can connect. Cloud Run does not publish a CIDR block of addresses. This method is not recommended.
The Unix Socket method is for Cloud SQL Proxy that Cloud Run supports. This is the connection method used internally to your container when Cloud Run is managing the connection to Cloud SQL. Note, for this method IP based hostnames are not supported in your client to connect to Cloud Run's Cloud SQL Proxy.
You can embed the Cloud SQL Proxy directly in your container. Then you can use 127.0.0.1 as the hostname part for the connection string. This will require that you create a shell script as your Cloud Run entrypoint to launch both the proxy and your application. Based on your scenario, I recommend this method.
The Cloud SQL Proxy is written in Go and the source code is published.
If you choose to embed the proxy, don't forget to add the Cloud SQL Client role to the Cloud Run service account.
I'm running Wildfly within Docker. I need to add users and set the configuration before the java process is started.
I can run the add-user.sh script to create a simple user:
/wildfly/bin/add-user.sh admin admin --silent
However, I need to create a management user that will be used for authenticating an instance with the managed instance. In the CLI the option is:
"Is this new user going to be used for one AS process to connect to another AS process?", reply yes.
Is there a way to set this option via a parameter in the script?
add-user.sh just adds the user to: mgmt-users.properties
so you can generate this value for yourself pretty easily.
This will give you access to the container
docker exec -it wildfly-instance /bin/bash
I am working on setting up auto deployment script using Python Fabric on EC2 instance. We are already having code repositories cloned on EC2 instance with HTTPS (without user name,https://bitbucket.org/) instead of SSH.
If we clone the repositories using SSH, it will solve my problem for now. But, I just wanted to know if following is possible:-
After connecting to remote EC2 instance using Fabric, if my next command is hg clone, it asks for user name and password. I have to type this two things manually on command prompt.
Is there any way we can pass these values run time automatically?
Thanks!
You can use ssh keys and connect using the ssh+hg protocol. It'll auth w/o password if you set that up.