4 ms·

How do you make a service call or ssh into a machine without a name?

scarface74 7y ago
IP Address. We have “servers” that get created and destroyed nightly based on how many items are in the queue. All of our web servers are behind autoscaling groups. Even the ones where we have a min/max of 2. If it doesn’t respond to a health check it gets killed and another one is brought up. Ideally, none of our servers are special.
Ao7bei3s 7y ago
You don't. Stop thinking in machines. Your code doesn't directly call a service, you'd use a service discovery framework (eg AWS Cloud Map) to lookup a location that can handle a particular type of request. It doesn't even matter to the caller whether the request is handled by an instance (eg EC2), a container (eg Fargate), or a function (eg Lambda). End user requests are handled by an application loadbalancer (eg ELB) that accepts the requests and routes them to an available location, which again doesn't need to be any particular machine (and it can also spawn/destroy instances as needed) or type. With serverless computing (eg AWS Lambda), there's not even machine for you to SSH into, the cloud takes care of executing functions "somewhere" to handle your work. Work could mean serving an HTTP request - however there doesn't even need to be a client making a call; the lambda could e.g. run in response to an event on an S3 bucket. Of course AWS can also handle your pets; ie you can name your EC2 instances (and either manage DNS outside, or use Route 53 to let AWS handle it). But that's not what AWS is about; there are way cheaper options for vServers. And of course there are real computers below this, and DNS is being used in the middle of this (with auto-generated names that you don't care about). But you don't deal with that.
- pradiptasarma 7y ago
  Why is this downvoted?
jedberg 7y ago
The first thing you should do is question why you're SSHing into a production server in 2019. But after that, usually you can do it by IP address or instance ID.
- maccard 7y ago
  OP never mentioned it was a production server. Also, sometimes, things get stuck, or you haven’t set up a pipeline to gather X data but y has happened, or there’s a deadlock in your source control host, or you’ve accidentally deleted the backup and the live service is the only copy of the data... all awful reasons and yet I’m sure they happen every day to people.
  - jedberg 7y ago
    I didn't say you should never ssh into an instance, I just said you should ask yourself why you're doing it first. Every one of the reasons you listed is a great thing to be cognizant of so that you can make a list/ticket/whatever to fix that problem so you won't need to ssh again to solve that problem.

IP Address. We have “servers” that get created and destroyed nightly based on how many items are in the queue. All of our web servers are behind autoscaling groups. Even the ones where we have a min/max of 2. If it doesn’t respond to a health check it gets killed and another one is brought up. Ideally, none of our servers are special.

Ao7bei3s 7y ago

You don't. Stop thinking in machines. Your code doesn't directly call a service, you'd use a service discovery framework (eg AWS Cloud Map) to lookup a location that can handle a particular type of request. It doesn't even matter to the caller whether the request is handled by an instance (eg EC2), a container (eg Fargate), or a function (eg Lambda). End user requests are handled by an application loadbalancer (eg ELB) that accepts the requests and routes them to an available location, which again doesn't need to be any particular machine (and it can also spawn/destroy instances as needed) or type. With serverless computing (eg AWS Lambda), there's not even machine for you to SSH into, the cloud takes care of executing functions "somewhere" to handle your work. Work could mean serving an HTTP request - however there doesn't even need to be a client making a call; the lambda could e.g. run in response to an event on an S3 bucket. Of course AWS can also handle your pets; ie you can name your EC2 instances (and either manage DNS outside, or use Route 53 to let AWS handle it). But that's not what AWS is about; there are way cheaper options for vServers. And of course there are real computers below this, and DNS is being used in the middle of this (with auto-generated names that you don't care about). But you don't deal with that.

pradiptasarma 7y ago
Why is this downvoted?

jedberg 7y ago

The first thing you should do is question why you're SSHing into a production server in 2019. But after that, usually you can do it by IP address or instance ID.

maccard 7y ago
OP never mentioned it was a production server. Also, sometimes, things get stuck, or you haven’t set up a pipeline to gather X data but y has happened, or there’s a deadlock in your source control host, or you’ve accidentally deleted the backup and the live service is the only copy of the data... all awful reasons and yet I’m sure they happen every day to people.
- jedberg 7y ago
  I didn't say you should never ssh into an instance, I just said you should ask yourself why you're doing it first. Every one of the reasons you listed is a great thing to be cognizant of so that you can make a list/ticket/whatever to fix that problem so you won't need to ssh again to solve that problem.