Is there documentation / examples of healthCheck f...
# getting-started
m
Is there documentation / examples of healthCheck for "awsx.ecs.FargateService" somewhere I can't find? For example:
Copy code
const service = new awsx.ecs.FargateService("service", {
        containers: {
            yourAppHere: {
                healthCheck: {
                    interval: 15,
                    command: ["ps", "x", "|", "grep", "puma", "|", "grep", "0.0.0.0:3000"]
                },
            }
        },
    },
});
Given the above, does it run the following command inside the container?
Copy code
ps x | grep | puma | grep | 0.0.0.0:3000
and pass if 0, fail if 1?
d
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
And yes, pass is 0, fail is non-zero
m
gotcha, so it seems that whereas now i use:
Copy code
command: ["ps", "x", "|", "grep", "puma", "|", "grep", "0.0.0.0:3000"]
what I mean to use is:
Copy code
command: ["CMD-SHELL", "ps", "x", "|", "grep", "puma", "|", "grep", "0.0.0.0:3000"]
?
d
Not quite, with CMD-SHELL, the whole command is kept together instead of being split into an array
So 2 items in the list
m
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?
d
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
m
that helps a bunch; thank you.
d
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
m
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
I've used k8 / ec2 before but not fargate - would you happen to know anything off the top of your head?
d
Been a while since I've done ecs. It could be memory limits, or healthchecks failing on the load balancer/target group
m
AWS LBs and Target Groups have their own checks?
my first time trying to use aws native stuff instead of k8/envoy/istio/etc
d
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
m
trying to do a setup this startup will be able to self-manage and it seems actually harder lol
wait... do target groups have their own checks?
d
They can do
m
Copy code
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":
Copy code
portMappings: [{
                    targetGroup: pmbMainLB.defaultTargetGroup,
                    containerPort: 3000,
                    hostPort: 3000
                }],
Will AWS terminate a fargate instance if its' corresponding target group fails?
the problem is this legacy ruby application takes A HOT MINUTE to load the first time - like 230sec. i have a feeling the ALB is timing it out and dropping before
seems like the fargate container receives sigint or sigkill the second an ALB timeout happens
d
There should be a way to set the grace period somewhere
m
found
Copy code
/**
     * 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
for the "awsx.ecs.FargateService" i already set a 360sec health check grace
d
From what I remember, using the fargate healthcheck (as you're setting up before) will defer the target group healthchecks
idleTimeout is to do with connections after the service is running. You don't want that too high
m
gotcha. i think you are right, in AWS console the Target Group is showing unhealthy: 1 even before the containers' grace period
Copy code
const pmbMainLB = new awsx.lb.ApplicationLoadBalancer("name", {
    defaultTargetGroup: {
        healthCheck: {
            enabled: false
        }
});
^ found that, will try
d
Try the ecs healthcheck first, see if it still terminates and if the TG eventually becomes healthy
m
well, i managed to finally get to the app server itself haha
idleTimeout on the ALB was it, kept dropping connections before app server replied. now im sleuthing around on how to set up security so fargate can connect to rds
d
So requests normally take longer than a minute?
m
no - just the first one that is cold before the legacy ruby app caches stuff
it kept failing the first cold hit and terminating the fargate container
d
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
m
yup..... 🥲
going to aws native networking/security from istio/envoy makes me feel like ET trying to phone home in the stone age
d
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
m
yup, just figured that out recently
how dumb of a rule is this?
Copy code
ingress : [{
        protocol : "tcp",
        fromPort : 5432,
        toPort : 5432,
        cidrBlocks : [vpc.vpc.cidrBlock],
    }],
wondering if there may be a more appropriate way to do least access
d
I think that let's everything in the vpc connect, probably not a good idea
Instead of cidrBlocks, you can use the
securityGroups
option
m
ty!
is the principle of a security group basically that any two resources with the same group can access each other?
d
nope, it's that you can define a rule to let other security groups through
like firewall rules, but extended to account for things not having static IPs. I found it easier to think of SGs as representing a service, and the rules let services talk to each other
m
gotcha; appreciate the help and the convo
here's a wild one - is there a way to create a client VPN endpoint and peer it with a VPC programatically? given the whole cert generation parts
d
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