I couldn't find any pictures(examples) of how AWS CodeBuild and CloudWatch logs integration looks like, therefore I've snapped some myself.

It looks alright and usable, especially logs available in build status. Better than fishing logs from S3.

— Zdenek Styblik 2021/06/04 15:06

Previously, I was praising AWS CodeBuild and CloudWatch Logs integration. Today, it's something else :) I was in need of quick-and-dirty CodeBuild project in order to try something. I've made couple mistakes along the way, but I still think and it's possible there are cases when logs won't appear in CloudWatch and when you still need to offload logs to S3 bucket.

[Container] 2021/06/14 15:05:28 Waiting for agent ping
[Container] 2021/06/14 15:05:31 Waiting for DOWNLOAD_SOURCE
[Container] 2021/06/14 15:05:32 Phase is DOWNLOAD_SOURCE
[Container] 2021/06/14 15:05:32 CODEBUILD_SRC_DIR=/codebuild/output/src123899037/src
[Container] 2021/06/14 15:05:32 YAML location is /codebuild/readonly/buildspec.yml
[Container] 2021/06/14 15:05:32 Phase complete: DOWNLOAD_SOURCE State: FAILED
[Container] 2021/06/14 15:05:32 Phase context status code: YAML_FILE_ERROR Message: wrong number of container tags, expected 1

btw there was no version: 0.2 in buildspec file.

[Container] 2021/06/14 15:46:59 Waiting for agent ping
[Container] 2021/06/14 15:47:02 Waiting for DOWNLOAD_SOURCE
mounting '127.0.0.1:/' failed. connection reset by peer

I had to setup S3 bucket(so much for quick) in order to get to the bottom of what exactly is wrong.

— Zdenek Styblik 2021/06/17 09:47

When migrating from Redis-as-a-queue to AWS SQS and making application more integrated with the cloud, we've decided to use a FIFO queue. Intentions were good - ideally keep order of messages and prevent duplicates as low as possible. We were aware of the following excerpt from FAQ:

By design, Amazon SQS FIFO queues don't serve messages from the same message group to more than one consumer at a time. However, if your FIFO queue has multiple message groups, you can take advantage of parallel consumers

but not so much of implications, at least for django-q. We've given it a try and it failed miserably due to combo of max attempts and buggy job running way past the limit.

As for the implications(which I haven't verified), FIFO means that only one job can be executed at the time and nothing else. Got django-q workers/threads? Pointless. Scaling? Yes, if you emit messages into different message groups and willing to accept the fact that some messages might not be processed at all on scale down. I'm fairly sure both of these can be solved, but is it worth it? Most likely no.

Therefore, we've switched to the simple SQS queue with no content deduplication(which probably didn't work anyway with this setup) and no FIFO and possibility of duplicates. However, that's life and it works.

— Zdenek Styblik 2021/06/25 20:56