I'm using an AWS SAM debug configuration in VS Code to execute Lambda code for Typescript/Node 14 inside a Docker container. I've run into problems of dependencies not being included in the Lambda image, and I presume that building the Lambda explicitly using sam build should resolve that. However, I can't find the template files that VS Code generates. Is there a way to export my settings from VS Code's launch.json, or otherwise get hold of the template.yaml?
The SAM template will be generated, at least on Mac, in a directory under
/tmp/aws-toolkit-vscode. E.g.:
/tmp/aws-toolkit-vscode/vsctkENG01e/app___vsctk___template.yaml
This directory gets mapped into the Docker container.
Related
I am trying to attach ca-certificates (pem files) to the docker image produced by spring-boot gradle plugin(buildpacks). The command I am using is ./gradlew bootBuildImage. This is working fine locally and is adding the certificates but when I run this from my gitlab pipeline I am getting the below errors:
I added some logging to the pipeline and it seems that even though the files (pem & type) are present and have the appropriate permissions, the pipeline runner is probably not having access to those, hence it fails. I dont see how I can add the files differently or execute a command in the builder to get them via wget/curl..
Here is my build.gradle configuration:
and the pem files are stored like this:
The error is not very helpful and documentation is not very great. Any idea is welcome.
I have added
environment = [
"BP_LOG_LEVEL": "debug"
]
and the /platform related sections (aside from the originally shared log) are here(mentioned a few times) :
EDIT: The certificates I am trying to add are AWS RDS ones. I did try changing the buildpacks builder image in an attempt to use a more appropriate (adoptium) one (containing the AWS root certificate) https://bugs.openjdk.org/browse/JDK-8233223 but with no luck.
I get the impression that it is a gitlab issue and have started exploring passing the pem files to the EKS pod differently.. maybe via SERVICE_BINDING_ROOT and k8s secrets.
I'm developing an application with micronaut using SAM CLI to deploy it on AWS Lambda. As I was including dependencies and developing new features, the function packages got bigger an bigger (now they are around 250MB). This makes deployment take a while.
On top of that every time I edit template.yaml and then run sam build && sam deploy to try a new configuration on S3, RDS, etc... I have to wait for gradle to build the function again (even though it's unchanged since the last deployment) and upload the whole package to S3.
As I'm trying to configure this application with many trials and errors on SAM, waiting for this process to complete just to get an error because of some misconfiguration is getting quite counterproductive.
Also my SAM s3 bcuket is at 10GB size after just a single day of work. This may get expensive on the long run.
Is there a way to avoid those gradle rebuilds and reuploads when teh function code is unchanged?
If you are only updating the template.yml file, you could copy the new version to ./.aws-sam/build folder and then run sam deploy
$ cp template.yml ./.aws-sam/build/template.yml
$ sam deploy
If you are editing a lambda you could try to update the function code by itself (after you create it in the template and deploy of course). That can be done via the AWS CLI update-function-code command:
rm index.zip
cd lambda
zip –X –r ../index.zip *
cd ..
aws lambda update-function-code --function-name MyLambdaFunction --zip-file fileb://index.zip
more info can be found here:
Alexa Blogs - Publishing Your Skill Code to Lambda via the Command Line Interface
AWS CLI Command Reference - lambda - update-function-code
my SAM s3 bcuket is at 10GB size
Heh. Yea start deleting stuff. Maybe you can write a script using aws s3?
I received following error in CloudWatch Logs after using AWS CodePipeline (AWS CodeBuild) to deploy my C# Lambda Function Code
Could not find the required 'MyAssembly.deps.json'.
This file should be present at the root of the deployment package.: LambdaException
The problem in my case was that the linux file permissions on files inside the Zip were set to 000; so when the zip was extracted by AWS Lambda; AWS Lambda did not have file permission to access the file MyAssembly.deps.json
I was using C# System.IO.Compression.ZipFile.CreateFromDirectory to author the zip file. I had to shell out to the native zip program to produce a zip file which worked.
Big thanks to https://forums.aws.amazon.com/message.jspa?messageID=856247
I know this is bit old question but writing answer for any user who are still facing the problem on windows system.
this is with dotnet core 3.1
The first command in package manager console to ensure the .deps.json included in publish files
dotnet publish /p:GenerateRuntimeConfigurationFiles=true
and than zip all files of publish folder in the same name of namespace folder. upload the zip file to AWS lambda using console.
worked.
If not than copy all project files ( not the published) in zip and upload to aws lambda.
I am trying to set up a CICD pipeline using Visual Studio > Visual Studio Team Services > Elastic Beanstalk Create version.
I have been able to check in my code OK, and kick off my build pipeline which contains the following step in place of 'publish artefact':
"Create Elastic Beanstalk Revision:"
This step is attached to an AWS IAM User with Administrator privileges. This step fails when I try to run my pipeline to deploy the ASP.NET application (Webforms, so not Core) via this method.
The error output is as follows:
2018-07-30T04:46:22.7765736Z ##[section]Starting: Create Elastic
Beanstalk Revision: Sparky 2018-07-30T04:46:22.7771363Z
============================================================================== 2018-07-30T04:46:22.7771634Z Task : AWS Elastic Beanstalk
Create Version 2018-07-30T04:46:22.7771964Z Description : Create an
application revision for deployment to an environment.
2018-07-30T04:46:22.7772192Z Version : 1.0.21
2018-07-30T04:46:22.7772403Z Author : Amazon Web Services
2018-07-30T04:46:22.7772908Z Help : Please refer to AWS
Elastic Beanstalk User
Guide
for more details on deploying applications with AWS Elastic Beanstalk.
2018-07-30T04:46:22.7773336Z
============================================================================== 2018-07-30T04:46:23.2641747Z ac747f99-1789-4d43-86c5-c8283d1a72c0
exists true 2018-07-30T04:46:23.2671026Z Deployment type set to aspnet
2018-07-30T04:46:24.8994140Z Determine S3 bucket
elasticbeanstalk-ap-southeast-2-153247006570 to store application
bundle 2018-07-30T04:46:24.9038683Z Upload of application bundle
failed with error: EISDIR: illegal operation on a directory, read {
Error: EISDIR: illegal operation on a directory, read
2018-07-30T04:46:24.9047409Z Uploading application bundle D:\a\1\a to
object Sparky/a-cicd_test.zip in bucket
elasticbeanstalk-ap-southeast-2-153247006570
2018-07-30T04:46:24.9048878Z ##[error]Error: EISDIR: illegal operation
on a directory, read 2018-07-30T04:46:24.9053846Z at Error
(native) errno: -4068, code: 'EISDIR', syscall: 'read' }
2018-07-30T04:46:24.9172250Z ##[section]Finishing: Create Elastic
Beanstalk Revision: Sparky
I could find very little (pretty much no) results online about this error. I'm not sure how to resolve it. Any ideas anyone? I know it's not IAM permissions as I am using ADMIN for the AWS User just for testing.
EDIT: Added image of build definition. (Note, I don't really know how to use version label output variables so just put something there, but I don't think that's the issue, this failure is something else entirely. I'm just following online example/tutorials for a basic deployment)
The build extension is https://aws.amazon.com/vsts/ and looking back over my screenshot and the instructions I was following here https://aws.amazon.com/blogs/developer/deploying-net-web-applications-using-aws-elastic-beanstalk-with-visual-studio-team-services/ I just realised a mistake! I didn't specify the file name in the web deploy archive.
I changed
$(build.artifactstagingdirectory)
To
$(build.artifactstagingdirectory)\SparkIdeaGenerator.zip
And the build succeeded! However, clearly I didn't understand the purpose of this build task, as it has only created an application revision in AWS, it hasn't actually deployed the updated code. This isn't much good, as I still need to go into the console and click 'Deploy'. This doesn't seem ideal. Here's what I mean:
Clearly I didn't understand the limits of this build task. I thought it would create the revision and deploy the code. It doesn't. There is only one other Elastic Beanstalk build task available in the toolset I downloaded, which is 'create application'. I don't want this, as I already have the application present, I Just want to update it. I will take a look further into this, as I need that full end-to-end automation, commit code, run build, deploy code, update site.
I will however mark the question as answered, as I have solved this specific question/error by specifically referencing a .zip with the package name of the solution itself.
The process is defined in: https://docs.aws.amazon.com/vsts/latest/userguide/tutorial-eb.html
It states that you use the zip file name along with the $(build.artifactstagingdirectory), like what was identified above.
This does appear to fix the issue.
I have asp core api project and i am using visual studio 2017 to run my project.
After i renamed the docker container that was previously created using visual studio using this command on command line,
docker rename CONTAINER NEW_NAME
I receive the following message when i try to run the project again in visual studio.
Thanks for the help
Can not find docker container with the name starting with 'previous_container_name'.
Delete the .vs folder in your solution directory (close the solution first), the Docker image name seems to be cached somewhere in there.
This error started happening to me when someone on the team unchecked the build checkbox for the docker-compose project. Make sure it is enabled in Build -> Configuration Manager
I had a similar problem, and it was caused because I started Docker after opening the project. VS does some things with Docker on opening of the project, and will fail if Docker is not started.
Lesson learned: make sure Docker is running before starting Visual Studio. If Docker is not started, then start Docker, close your solution, and re-open it.
VS will re-create the container as it opens the project.
This happened for me because I stopped a container manually via the commandline, then Visual Studio got confused.
To get round the issue I simply added a single ' ' space character to docker-compose.yml and saved the file. This forced Visual Studio to restart the container and connect to it.
I'm sure starting/stopping Visual Studio would also have worked, but the whitespace change was nice and fast.
I also have the similar problem.
These steps always help me to solve the issues.
Solution 1:
1- Close VS
2- delete obj folder of root solution folder.
3- delete obj folder of all projects which are involved in docker-compose file.(example all APIs)
4- Open VS
5- Remove the docker-compose project from solution and add it again.
During the creation process, don't overwrite the old files with new ones, to prevent deletion of you current docker-compose.yml configuration.
Solution 2:
On the first time of container creation, copy the creation command:
example: docker-compose -f "[path]\docker-compose.yml" -f "[path]\docker-compose.override.yml" -f "[path]\docker-compose.vs.debug.g.yml" -p dockercompose17926074389345686639 --no-ansi up -d --no-build --force-recreate --remove-orphans
any time there is an error just run this command manually.
if anybody could find a constant solution please also let us know.
One more cause is using solution folders for your docker project and a version of Visual Studio 2017 less than 15.9, upgrading to 15.9+ fixed this for me, see this issue.
In my case i have tried all of those but solution is very simple in V.S. 2019
Before all there is a bugfix packet for visual studio 2017 even if you using 19 beta, for this on https://visualstudio.microsoft.com/vs/
Download and install that pocket.
For automatically composing also you should add Docker Compose Support follow this link https://learn.microsoft.com/tr-tr/dotnet/standard/containerized-lifecycle-architecture/design-develop-containerized-apps/visual-studio-tools-for-docker
1-) Right click to targeted project root folder on solution explorer that contains Dockerfile and select add-> Docker Support it will ask you its always contains would you like to create new one? Click yes. It will create new Dockerfile.
You will see some changes in new Dockerfile like your project changes or nuget package changes affectness
2-) Right click the newly replaced Dockerfile and Build Image.
It will successfully build
3-) Choose debugger as Docker instead IIS Express vs. Even don't use other debugger while developing project if you do not need
In my case, I had both the "image" section and the "build" section in my docker-compose.yml. I just removed the build section because I wanted it to pull an image from the docker registry, and now it is working.
If your project uses Launch profiles to run, I fixed this with the following steps:
Open Manage Docker compose launch settings VS.
Select the Launch Profile you are currently using to run the application.
Check id the specific service is selected in the launch profile or not. All the services you intent to run should be part of the Launch profile.