This message was deleted.

It's pretty much the same as

HEALTHCHECK

in docker. Some useful docs for you for ECS specifics: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-healthcheck.html I think with pipes, you'll need to use the

CMD-SHELL

varient

gotcha, so it seems that whereas now i use:

command: ["ps", "x", "|", "grep", "puma", "|", "grep", "0.0.0.0:3000"]

what I mean to use is:

command: ["CMD-SHELL", "ps", "x", "|", "grep", "puma", "|", "grep", "0.0.0.0:3000"]

?

Not quite, with CMD-SHELL, the whole command is kept together instead of being split into an array

whoops, read the article wrong. been trying to get some stuff on aws to work with pulumi for 10 hours now 😓 ty. Is it a safe assumption that most of the pulumi arguments that are not explicitly documented map to the AWS docs and can just be found there?

For the awsx package, there might be more abstractions. But yes it should map well. I find looking at terraform and API examples useful for reference, too

that helps a bunch; thank you.

Also, I linked the cloudformation docs instead of the ecs api docs. Shows how similar things can be 😂 https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HealthCheck.html

this is a shot in the dark but I've got an old legacy app that i have the misfortune of migrating from heroku to aws - i put a ruby docker image into ecs fargate; it appears to be sending SIGKILL or SIGTERM to the container every few minutes

Been a while since I've done ecs. It could be memory limits, or healthchecks failing on the load balancer/target group

AWS LBs and Target Groups have their own checks?

Metrics + logs should help for checking for a memory issue. You can check the target groups in the ec2 dashboard, which will tell you their status

trying to do a setup this startup will be able to self-manage and it seems actually harder lol

They can do

const pmbMainLB = new awsx.lb.ApplicationLoadBalancer("pmb-main-alb", {
    name: "pmb-main-web-traffic-alb",
    defaultTargetGroup: {
        port: 3000
    },
    listener: {
        port: 80
    },
});

^ That's my pulumi ALB config, with this in "awsx.ecs.FargateService":

portMappings: [{
                    targetGroup: pmbMainLB.defaultTargetGroup,
                    containerPort: 3000,
                    hostPort: 3000
                }],

Will AWS terminate a fargate instance if its' corresponding target group fails?

There should be a way to set the grace period somewhere

found

/**
     * The time in seconds that the connection is allowed to be idle. Only valid for Load Balancers of type `application`. Default: 60.
     */
    idleTimeout?: pulumi.Input<number>;

in ApplicationLoadBalancerArgs, will try

From what I remember, using the fargate healthcheck (as you're setting up before) will defer the target group healthchecks

gotcha. i think you are right, in AWS console the Target Group is showing unhealthy: 1 even before the containers' grace period

Try the ecs healthcheck first, see if it still terminates and if the TG eventually becomes healthy

well, i managed to finally get to the app server itself haha

So requests normally take longer than a minute?

no - just the first one that is cold before the legacy ruby app caches stuff

Oof. I've worked on a rails app like that before. Load up without the cache, that's 15 minutes for the homepage while the taxonomy builds

yup..... 🥲

It's not too bad. For what you need, it should be attaching a security group to the rds, and adding an ingress rule that lets your ecs security group through

yup, just figured that out recently

I think that let's everything in the vpc connect, probably not a good idea

ty!

nope, it's that you can define a rule to let other security groups through

gotcha; appreciate the help and the convo

hmm, the example in the docs are a little broken, as it's using the Terraform references. When you see something like

aws_acm_certificate

, then it'll usually be under pulumi as

aws.acm.Certificate