By using AWS re:Post, you agree to the Terms of Use
/Developer Tools/

Developer Tools

Host code, build, test, and deploy your applications quickly and effectively with AWS Developer Tools. Leverage core tools like software development kits (SDKs), code editors, and continuous integration and delivery (CI/CD) services for DevOps software development. Use machine learning (ML)-guided best practices and abstractions to improve agility, security, velocity, and code quality.

Recent questions

see all
1/18

Using Elastic Beanstalk - Docker Platform with ECR - Specifying a tag via environment variable

Hi, I am trying to develop a CI/CD process, using Beanstalk's Docker platform with ECR. Code Pipeline performs the builds and manages ECR Tags & Promotions. Terraform manages the infrastructure. I am looking for an approach that allows us to use the same Dockerfile/Dockerrun.aws.json in production & non-production environments, despite wanting different tags of the same image deployed.. Perhaps from different repositories (repo_name_PROD vs repo_name_DEV ). Producing and moving Beanstalk bundles that only differ in a TAG feels unnecessary. the idea of dynamically changing Dockerfiles using the deployment process also seems fragile. What I was exploring was using a simple Environment variable: change what tag (comitHash) of an image should be based on a Beanstalk environment variable. ``` FROM 00000000000.dkr.ecr.us-east-1.amazonaws.com/repoName:${TAG} ADD entrypoint.sh / EXPOSE 8080 8787 9990 ENTRYPOINT [ "/entrypoint.sh" ] ``` Where TAG is the Git hash of the code repository from which the artifact was produced. CodeBuild has built the code and tagged the docker image. I understand that Docker supports this: ``` ARG TAG FROM 00000000000.dkr.ecr.us-east-1.amazonaws.com/repo_name:${TAG} ADD entrypoint.sh / EXPOSE 8080 8787 9990 ENTRYPOINT [ "/entrypoint.sh" ] ``` but requires building the image like this: `docker build --build-arg GIT_TAG=SOME_TAG . ` Am I correct in assuming this wil not work with the docker platform? I do not believe the EB Docker platform exposes a way to specify the build-arg. What is standard practice for managing tagged docker images in Beanstalk. I am a little leery of the `latest` tag.. as a poorly timed auto scaling event could pull an update before it should be deployed: that just does not work in my case. Updating my Dockerfile dufing deployment (via `sed` ) seems like asking for trouble.
0
answers
0
votes
1
views
bchandley
asked a day ago

Is it possible to use a non-default bridge network when running CodeBuild locally?

When I run codebuild locally it creates the default docker network and volumes as in the below output. Is there a way to use different bridge network and volumes instead of these default ones? I tried modifying the docker command in [codebuild_build.sh](https://github.com/aws/aws-codebuild-docker-images/blob/master/local_builds/codebuild_build.sh) to add a network (below build command output shows `--network mylocaltestingnetwork`) but that didn't help as such. The reason I am trying to use a different network and volumes is because I am using [localstack](https://localstack.cloud/) along with it, and the bridge network and volumes need to be accessible from the codebuild local container. If I configure my localstack to use the `agent-resources_default` network created by local codebuild then codebuild is able to access localstack. But, I would like to keep the dependency external to both codebuild and localstack by using a separate bridge network. ``` $ ./codebuild_build.sh -i public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:3.0 -a codebuild-output/ -b buildspec-local.yml -c -p localstack Build Command: docker run -it -v /var/run/docker.sock:/var/run/docker.sock -e "IMAGE_NAME=public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:3.0" -e "ARTIFACTS=<repo path>/codebuild-output/" --network mylocaltestingnetwork -e "SOURCE=<repo path>" -e "BUILDSPEC=<repo path>/buildspec-local.yml" -e "AWS_CONFIGURATION=<homedir>/.aws" -e "AWS_PROFILE=localstack" -e "INITIATOR=<user>" public.ecr.aws/codebuild/local-builds:latest Removing network agent-resources_default Removing volume agent-resources_source_volume Removing volume agent-resources_user_volume Creating network "agent-resources_default" with the default driver Creating volume "agent-resources_source_volume" with local driver Creating volume "agent-resources_user_volume" with local driver Creating agent-resources_agent_1 ... done Creating agent-resources_build_1 ... done Attaching to agent-resources_agent_1, agent-resources_build_1 agent_1 | [Container] 2022/01/14 15:57:15 Waiting for agent ping agent_1 | [Container] 2022/01/14 15:57:17 Waiting for DOWNLOAD_SOURCE agent_1 | [Container] 2022/01/14 15:57:23 Phase is DOWNLOAD_SOURCE ```
0
answers
0
votes
1
views
bbideep
asked 2 days ago

aws-sdk V3 timeout in lambda

Hello, I'm using NodeJS 14.x lambda to control an ecs service. As I do not need the ecs task to run permanently, I created a service inside the cluster so I can play around the desired count to start or stop it at will. I also created two lambdas, one for querying the current desired count and the current Public IP, another one for updating said desired count (to 0 or 1 should I want to start or stop it) I have packed aws-sdk v3 on a lambda layer to not have to package it on each lambda. Seems to work fine as I was getting runtime error > "Runtime.ImportModuleError: Error: Cannot find module '@aws-sdk/client-ecs'" But I do not anymore. The code is also working fine from my workstation as I'm able to execute it locally and I get the desired result (query to ecs api works fine) But All I get when testing from lambdas are Timeouts... It usually execute in less than 3 secondes on my local workstation but even with a lambda timeout set up at 3 minutes, this is what I get ``` START RequestId: XXXX-XX-XXXX Version: $LATEST 2022-01-11T23:57:59.528Z XXXX-XX-XXXX INFO before ecs client send END RequestId: XXXX-XX-XXXX REPORT RequestId: XXXX-XX-XXXX Duration: 195100.70 ms Billed Duration: 195000 ms Memory Size: 128 MB Max Memory Used: 126 MB Init Duration: 1051.68 ms 2022-01-12T00:01:14.533Z XXXX-XX-XXXX Task timed out after 195.10 seconds ``` The message `before ecs client send` is a console.log I made just before the ecs.send request for debug purposes I think I've set up the policy correctly, as well as the Lambda VPC with the default outbound rule to allow all protocol on all port to 0.0.0.0/0 so I I have no idea on where to look now. I have not found any way to debug aws-sdk V3 calls like you would do on V2 by adding a logger to the config. Maybe it could help understanding the issue....
1
answers
0
votes
5
views
Tomazed
asked 5 days ago

Popular users

see all
1/18

Learn AWS faster by following popular topics

1/1