-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Health checks fail when using the new publish to elastic beanstalk interface #311
Comments
Further info: our environment does not use a proxy server Further investigation: The artifacts produced by the legacy deploy process are quite different to the new version.
|
Thank you for bringing this issue to our attention. To be sure I understand correctly, you deployed to a Beanstalk environment using the "Publish to AWS Elastic Beanstalk (Legacy)" option in the AWS Toolkit. Subsequently, you attempted to deploy the same project to the same Beanstalk environment using the "Publish to AWS" option. Do I have that correct? |
Hi! Yes that is correct. |
Do you see this behavior consistently when deploying with Publish to AWS? Do the legacy deployments work or fail as well? If you haven't already, let's take a look at your log files. From Visual Studio, if you click on Extensions in the main menu then AWS Toolkit then View Toolkit Logs. Do you see any warnings/errors related to the deployment in those logs? If so, please post the details in this issue. The toolkit uses the AWS dotnet deploy tool to perform these actions. What results do you get when trying to deploy this project using the deploy tool directly? https://aws.github.io/aws-dotnet-deploy/docs/commands/deploy/ |
Hi, I just wanted to let you know it's been a busy start to the year and I will get those logs for you asap - The logs I have are full of other noise so I wanted to get a "clean" version for you. The behaviour is consistent and the legacy version does not fail. I think the main difference here will be the commands used to create the deploy artefacts as the packages are quite different. Hopefully the logs will shed some light. Also, FYI, this affects more than one project/application. |
Some company info redacted Here's the output of the logs from the new publish 2023-01-06 09:40:56,363 [113] INFO Amazon.AWSToolkit.Credentials.Core.ProfileCredentialProviderFactory - Reloaded AWS Credential Profiles And the output in the deploy tab Creating Dotnet Publish Zip file... Uploading to S3. (Bucket: elasticbeanstalk-eu-west-1-XXXXX Key: XXXXX.ServicesSales/AWSDeploymentArchive_XXXXX.ServicesSales_v-XXXXX.zip Size: 6151000 bytes) Getting latest environment event date before update |
Logs from legacy deploy 2023-01-06 10:19:01,432 [1] INFO Amazon.AwsToolkit.VsSdk.Common.VSWebProjectInfo - EnvDTEProject.FullName lookup yielded 'C:\Dev\XXXXX\XXXXX\XXXXX.services.sales\XXXXX.Services.Sales\XXXXX.Services.Sales.csproj' |
There's not really much useful info in the logs from what I can see. The output doesn't appear to include the command used to the invoke the deploy tool. I'll try the command line directly asap. Do both legacy and new versions use the same command line? I'd highlight again that the deploy artefacts in the packages produced are VERY different. I can raise a support ticket in AWS if it helps? I'd be willing to share the artefacts there but not on here |
Hi @alexsaare - I've created aws/aws-dotnet-deploy#749 over on the AWS Deploy Tool for .NET CLI repository. The CLI handles the packaging for Beanstalk and powers the experience in Visual Studio, so any change we'll have to make will likely originate in that repository. We'll review the packaging differences and how we're handling the health checks. If you are able to route a ticket through support to us, the correct location internally is "AWS SDK for .NET" within the "SDKs and Tools" team. |
Thanks @ashovlin. I created a support case 11835795821 and attached both versions of the deploy package. I had to re-zip the new version using 7Zip to get it under 5MB so I could attach it to the case. |
Thanks, just heard from the support engineer internally who is routing the case to our queue. |
Just thought I'd add that in the output console the legacy deploy includes the following dotnet publish "C:\Dev\XXXXX\XXXXX\XXXXX.services.sales\XXXXX.Services.Sales" --output (Company redacted) |
@alexsaare I'm struggling to reproduce the issue. Would you mind running the following PowerShell command for each the environment that was created with the legacy wizard and the new wizard? You will need to update the region, profile, beanstalk application name and beanstalk environment name that you have. It will print out all of the Beanstalk option settings so we can compare what is different about the 2 different environemnts.
|
Hi @normj, thanks for taking the time to look into this. Apologies if I wasn't clear or I've misunderstood something here. No environment has been created using the new wizard. I only have existing environments which were created via the aws console. Deploying to these environments works via the legacy wizard however, when using the new wizard, it fails. Looking at the assets created by the 2 different wizards they are very different (see support case created). I can give you the output of the powershell requested for a environment that works with the legacy wizard but I don't have any environment that was created or works with the new wizard (that's the problem!) Does that help clarify the issue? Do you still need the powershell output? |
@alexsaare that does help and I was misunderstanding the situation. If you wouldn't mind running the PS script on the existing environment that would be appreciated. |
thanks @normj Output below - company/account info redacted - if you need anything I've redacted I can add it to the support case, just let me know $.Namespace, $.OptionName, $_.Value{aws:autoscaling:asg, Availability Zones, Any} |
Thanks this helps. I created an environment from the console with rolling deployments with 5 instances and I was able to deploy from both the legacy wizard and the new wizard. I see some differences in our environments based your settings above. In particular I have enhanced health enabled and your does not. So it gives me more things to try. |
Describe the bug
Health checks fail when using the new publish to elastic beanstalk interface
To Reproduce
Expected behaviour
Application should be deployed the same as legacy interface
Computer (please complete the following information):
Additional context
Deploying .NET 6 application to Amazon Linux 2/2.4.2. "Publish to AWS Elastic Beanstalk (Legacy)" works as expected. Health check simply checks for 200 from specific end point,. Using ELB type Application Loadbalancer. Environment has 5 instances of t3a.small and is part of a VPC. Uses rolling deploy based on health with batch size of 50%. Application version is successfully pushed to instances in first batch but instances are not re-registered with loadbalancer gets stuck on the step saying "Registering instance(s) with the load balancer and waiting for them to be healthy." Under "causes" in the console no error codes are shown.
The text was updated successfully, but these errors were encountered: