It seems like the best way to deploy a external facing application on Google Cloud would be to create an external load balancer with this line in the service configuration:
{
...
"createExternalLoadBalancer": true
...
}
This doesn't seem to work for AWS. I'm getting the following error when running the service create:
requested an external service, but no cloud provider supplied
I know about the PublicIPs setting in services, but that would involve knowing the service's IP in advance so I can set a domain name to it, but so far that doesn't look to be possible if I want to set it up using an external service like AWS ELB.
What's the recommended way of doing this on AWS?
This is still a work in progress.
Please see:
https://github.com/GoogleCloudPlatform/kubernetes/pull/2672
For a proposal that starts to add support for AWS ELBs to Kubernetes, we're working to get that pull request integrated.
Thanks!
Related
I have a dockerized Node.JS express application that I am migrating to AWS from Google Cloud. I had done this before successfully on the same project before deciding Cloud Run was more cost effective because of their free tier. Now, wanting to switch back to Fargate, but am unable to do it again due what I'm guessing is a crucial step. For minimal setup, I used the following guide: https://docs.docker.com/cloud/ecs-integration/ Essentially, using docker compose up with aws context and project name to deploy to ECS and Fargate.
The Load Balancer gives me a public DNS name in the format: xxxxx.elb.us-west-2.amazonaws.com and I have defined a port of 5002 in my Docker container. I know the issue is not related to exposing port numbers or any code-related issue since I had this successfully running in Google Cloud Run. When I try to hit any of my express endpoints, by sending POST to xxxxx.elb.us-west-2.amazonaws.com:5002/my_endpoint, I end up with Error: Request Timed Out
Note: I have already verified that my inbound security rules have been set to all traffic.
I am very new to AWS, so would love guidance if I am missing a critical step.
Thanks!
EDIT (SOLUTION): Turns out everything was deploying correctly, but after checking CloudWatch Logs, it turns out Fargate can't read environment variables defined inside of docker-compose file. Instead, they need to be defined in .env files, then read in docker-compose through -env-file flag. My code was then trying to listen on a port that was in environment variable but was undefined, so was receiving the below error in CloudWatch.
I have read other questions about this that all mention enabling service discovery, but my issue is a little different as to how to go about setting this up for my current Fargate deployments.
I have four spring boot api containers built via Gradle, pushed to ECR, and deployed in ECS Fargate with Terraform IaC setting up the appropriate resources. Three of these containerized apis have environment variables set within them to reference the fourth container, thus making an external api call outside of the container to that one service. DNS and 443 load balancer is setup for these deployments.
I have created a new service in the cluster containing the api that needs to be discovered. I have enabled service discover and created a local CloudMap A record for the api and then set each environment variable in the other containzers to use that local A record url, e.g., ecsservicename.local. Additionally I have tried to dig the service that I am connecting to in the other apis and that returns an IP so I am sure that that is working.
My questions are as follows:
(1) Since really only one services should be picked up by the others, was it correct to set service discovery on that one api and not the others or should I set up service discovery on all the other apis?
(2) Even if route53 is setup should this be an A record or SRV? I was confused by the documentation as to when to use which on aws.
(3) Is there a better or easier approach to use for inter-container communication that I am missing?
That's correct. Discovery should be set only for the one service. Other discoveries are not needed, as you are not inter-connection to those other services.
SRV also gives port, so from docs:
if the task definition that your service task specifies uses the bridge or host network mode, an SRV record is the only supported DNS record type.
I think your architecture is well thought and can't think of anything "easier" or better.
I'd like to have my Google Cloud Run services privately communicate with one another over non-HTTP and/or without having to add bearer authentication in my code.
I'm aware of this documentation from Google which describes how you can do authenticated access between services, although it's obviously only for HTTP.
I think I have a general idea of what's necessary:
Create a custom VPC for my project
Enable the Serverless VPC Connector
What I'm not totally clear on is:
Is any of this necessary? Can Cloud Run services within the same project already see each other?
How do services address one another after this?
Do I gain the ability to use simpler by-convention DNS names? For example, could I have each service in Cloud Run manifest on my VPC as a single first level DNS name like apione and apitwo rather than a larger DNS name that I'd then have to hint in through my deployments?
If not, is there any kind of mechanism for services to discover names?
If I put my managed Cloud SQL postgres database on this network, can I control its DNS name?
Finally, are there any other gotchas I might want to be aware of? You can assume my use case is very simple, two or more long lived services on Cloud Run, doing non-HTTP TCP/UDP communications.
I also found a potentially related Google Cloud Run feature request that is worth upvoting if this isn't currently possible.
Cloud Run services are only reachable through HTTP request. you can't use other network protocol (SSH to log into instances for example, or TCP/UDP communication).
However, Cloud Run can initiate these kind of connection to external services (for instance Compute Engine instances deployed in your VPC, thanks to the serverless VPC Connector).
the serverless VPC connector allow you to make a bridge between the Google Cloud managed environment (where live the Cloud Run (and Cloud Functions/App Engine) instances) and the VPC of your project where you have your own instances (Compute Engine, GKE node pools,...)
Thus you can have a Cloud Run service that reach a Kubernetes pods on GKE through a TCP connection, if it's your requirement.
About service discovery, it's not yet the case but Google work actively on that and Ahmet (Google Cloud Dev Advocate on Cloud Run) has released recently a tool for that. But nothing really build in.
I am trying to host an Elasticsearch Application on an AWS Server. For this purpose I am using Elastic Enterprise Search. I configured the API connector as follows:
const connector = new AppSearchAPIConnector({
searchKey: "search-gs7t3micqu41z1dsou1ccz95",
engineName: "sentence-similarity",
endpointBase: "http://ec2-18-159-135-25.eu-central-1.compute.amazonaws.com:3002"
});
The application itself is running with npm under port 3000. I enabled both ports in the AWS Security Group.
After starting both Elastic Search and Enterprise Search, after npm start I can also connect to http://ec2-18-159-135-25.eu-central-1.compute.amazonaws.com:3000, so that works. However, once I make an API call over the application, I get the following error:
POST
http://ec2-18-159-135-25.eu-central-1.compute.amazonaws.com:3002/api/as/v1/engines/sentence-similarity/search.json
net::ERR_CONNECTION_REFUSED
Moreover, when I type curl http://localhost:3002/api/as/v1/engines/sentence-similarity/search.json in the console, I get the following error:
{"error":"You need to sign in or sign up before continuing."}
Therefore I assume, that there is a problem with the connection to Elasticsearch. When I was hosting the application on my local machine, I never encountered this problem.
My ideas, how to possibly fix the problem:
I had to reinstall Elastic Search and Enterprise Search on the AWS
Server. Possibly, something with the authentification went wrong, and
I cannot connect to my Elasticsearch engine.
There are two .yml files, one for Elastic Search and one for Enterprise Search, which I can configure. Possibly, I have to adjust these, when I host the application not on my local machine.
In any case, I am a beginner in deployment and I need some help for the details. Thank you very much in advance!
EDIT:
After some more research, I believe I identified the problem. It seems like on the AWS server, there is sort of a new Elastic Enterprise instance established. That means, that there is no engine configured yet, which is why the API call fails. How can I connect to my existing engine instead of having to create a new one?
Well I have not used the AWS Elastic search but i can give some suggestions, check below urls,
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-vpc.html#kibana-test
https://www.youtube.com/watch?v=mWRo_JVgP_0
Also consider checking security groups.
I have been trying to install Pivotal Cloud Foundry on AWS and I have troubles with it.
In the section upload-cert mentioned that I need to create SSL Certificates for:
*.system.example.com
*.login.system.example.com
*.uaa.system.example.com
*.apps.example.com
So, I've created domain xxxxx.com on AWS Route53 and created a certificate on AWS ACM for domain and subdomains.
So, my questions are:
do I need to create subdomains (system, login, uaa, apps) in AWS Route53
do I need to bound my domain and subdomain somehow to PCF? Or the installation process had to do it for me?
for now, if I open http://login.xxxxx.com/ it responses with 503. what can be the reason?
what is the correct url to open the PCF UI?
I have such error in Ops Manager. What can be the reason of such error?
The same about logs. When I tried to download logs for failed services it failed too. What can be the reason?
Thank you for the help!
do I need to create subdomains (system, login, uaa, apps) in AWS Route53
do I need to bound my domain and subdomain somehow to PCF? Or the installation process had to do it for me?
You can create a wildcard subdomain (*.xxxxx.com) and alias using the instructions here: https://docs.pivotal.io/pivotalcf/1-10/customizing/cloudform-er-config.html#cname
what is the correct url to open the PCF UI?
If you mean Ops Manager, it is whatever DNS entry you created and pointed to the Ops Manager public IP address in this step: https://docs.pivotal.io/pivotalcf/1-10/customizing/cloudform-om-deploy.html#create-dns
For the ERT UI, there is the Pivotal Apps Manager https://docs.pivotal.io/pivotalcf/1-10/console/index.html
which is usually apps.system.xxxx.com
You can see what system apps are deployed by connecting to Cloud Foundry using the CLI and seeing which apps are in the system org, and what their routes are.
for now, if I open http://login.xxxxx.com/ it responses with 503. what can be the reason?
If the DNS has not been set up, I'm surprised you're getting any response whatsoever. Usually you get 503s when the routers connected to the load balancers are failing for some reason (http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ts-elb-error-message.html#ts-elb-errorcodes-http503)
I have such error in Ops Manager. What can be the reason of such error?
This would explain the 503s if the router is unhealthy. I would SSH into those machines and see what the logs say (in /var/vcap/sys/logs), which should tell you what is going wrong.
The reason of the red instances on the Status page was that my AWS account had limit on number of instances and it failed to create VMs for this nodes.
To find more information open Changelog (https://ops_manager_host/change_log) and the open log of the FAILED setup.