Elastic Beanstalk only allows deployment of .net or .netcore

[BookOfGreg]

Hi AWS team, I'm running VSTS on a self-hosted linux server and I'm having to use a shell script to eb deploy as this tool only caters for .net or .netcore. Can I ask for it to support the same options as the awsebcli? That tool is not opinionated about what languages are deployed.

Thanks.

[stevejroberts]

The existing task can deploy non-.NET code to Beanstalk but it may not be as obvious.

In your build process, before the task, you create the necessary deployment bundle in whatever way is appropriate for the language in use and target runtime, then upload it to S3. Then, in the Beanstalk Deployment task's configuration you select the 'Existing deployment bundle in Amazon S3' option for the Deployment Bundle Type option and configure the task with the bucket and object key of the bundle you uploaded.

Does this work for you? If not, what changes do you need?

[BookOfGreg]

Hi @steveataws , The docs for creating a version are similarly based on .net core also. I am able to deploy using the eb cli without having to manually upload a version. https://docs.aws.amazon.com/vsts/latest/userguide/elastic-beanstalk-createversion.html

Why isn't this project called aws-vsts-dotnet-tools if it's only intending to cater for one language?

[stevejroberts]

I guess I must be missing something in what you are trying to achieve but the tools do not cater for only one language. Assuming you have the ability to create the deployment bundle that Beanstalk expects, and upload it to S3, both tasks allow you to simply reference the uploaded bundle during version creation or deployment.

It's certainly true we do not use the eb cli to perform any work - to do so would require either you or the tasks install the necessary cli onto the build host, which takes time and therefore (assuming you are not using on-premise TFS) counts against your build minutes. Instead we call the native Beanstalk APIs. If you want to use the eb cli though, nothing is stopping you simply creating a shell, installing it and running the necessary commands - exactly what's you'd have had to do before these tools came along.

What kind of app are you trying to deploy that's causing you an issue? If we need to extend these tasks with some extra options to help make it easier then we can certainly consider it but as things stand, so long as you are able to create the bundle and have an existing Beanstalk environment to deploy to, they should be able to handle the process.

[BookOfGreg]

If I have a node, Java, Python, Ruby or Docker app, I can simply run eb deploy on the command line in order deploy that code to an elastic beanstalk location.

I had hoped to use this marketplace integration to wrap and parameterize pipeline variables such as the aws profile/secret key and ID, application name and env. However this tool only works on dotnet core or zipfiles. It's unusable on a basic python flask app because my only 2 automated options are dotnet even though there is no additional config required for a flask app.

[stevejroberts]

Are you able to build your app (or construct the necessary staging folders and contents if there is no 'build') without using the eb cli? I don't want to take a dependency on having to install the eb cli in this task, especially since you could just run it yourself from a shell task anyway. However, if we added the option to enable the task to pick up a folder in the build workspace (and zip it automatically), or have it point at an arbitrary zip file in the build workspace, would that help?

In terms of the existing two .net modes, all they largely do is create a zip file if pointed at a folder. They don't actually build the code, instead relying on upstream tasks to do that (msbuild or dotnet publish). For .net core there is a little more work done to construct the zip file with the right layout and content but it still depends on previously built content to that point.

Assuming adding arbitrary zip/folder support to the task would help, are there any other options in the eb cli that you use that are missing and should be considered?

[BookOfGreg]

Yep, I now take that approach when building in the pipeline. I use

git archive -v -o ${OUT_DIR}/app.tar --format=tar HEAD
tar -uf ${OUT_DIR}/app.tar node_modules/
gzip ${OUT_DIR}/app.tar

If I were to zip rather than tar.gz, is it possible using this tool to then deploy that to EB either directly or by creating an app version?

Accidental close, sorry.

[stevejroberts]

I don't think it matters whether you create a zip or a tar.gz archive, to be able to use the tools as they are today you need to upload whatever archive you create to S3 before you then use the create app version or deploy tasks. In those tasks you then use the existing archive in S3 mode to reference the archive in the S3 bucket.

In the enhancement I'm thinking of, you'd be able to avoid the preliminary S3 upload by pointing the two Beanstalk tasks at the local archive file or folder. If a folder was specified the tasks would then create a zip file from it for you before proceeding to handle the S3 upload on your behalf.

[BookOfGreg]

In the enhancement I'm thinking of, you'd be able to avoid the preliminary S3 upload by pointing the two Beanstalk tasks at the local archive file or folder.

This sounds like it would be useful to me as my reason for looking at this tool was in order to encapsulate the aws credentials, not having to upload manually to S3 first would help me to hide those.

[stevejroberts]

Ok, we'll see what we can get done, should be a relatively easy enhancement.