DEV Community: Dzhuneyt

Synology - Container Manager - Run a Docker Compose Project on CRON schedule

Dzhuneyt — Fri, 22 Mar 2024 13:42:42 +0000

I have a Synology NAS at home that I use for various purposes. One of the things I do with it is run a Docker Compose
project that contains a few services.

I have a few services that I want to run on a schedule. For example, a backup service that
runs every night or a media optimizer container that takes my movie library and converts it to playback formats, that
are more suitable for older smart TVs.

In this post, I will show you how to run a Docker Compose project on a schedule using the Synology Container Manager and
the Synology Task Scheduler.

Prerequisites

You will need to use Google Chrome or another browser that allows you to inspect Network requests.

Getting the Docker Compose project ID

Inspecting the Network requests is the only way to retrieve the unique ID that Synology uses to identify the Docker
Compose project.

We will need this ID later, so let's first explore how to find it.

Assuming you already created a "Project" inside "Container Manager" (a project is a fancy name that DSM uses for Docker
Compose stacks). Open the "Container Manager" and navigate to the project you want to run on a schedule. If it was
already running, stop it.

Before starting it again, open the Network inspector of your browser. If you are using Chrome on a Mac, you can do this
via Cmd + Option + I and then click on the "Network" tab. Other browsers obviously have similar developer tools but
you need to Google a bit how to find it, if you haven't used it before.

Hit the "Clear network log" button at the left of this floating window if you want to reduce clutter. Finally, start the
project by clicking the "Start" button in the Container Manager and observe the Network requests. You should find one
that looks like this:

SYNO.Docker.Project

Open it, and inside the "Payload" tab, you will find a JSON object that contains the ID of the project. It should be
something long and random looking, for example:

9fb91ca5-d817-42f8-8ddc-2acdf4d94494

Take note of this ID, because you will need it in the next step.

Scheduling a CRON job via Synology Task Scheduler

Open the Control Panel of your Synology NAS and navigate to the "Task Scheduler" app. Click on "Create" and then "
Scheduled Task" -> "User-defined script".

Name your task based on your preferences, e.g. "Run Backup service on schedule".

In the "User" dropdown, select "root"; otherwise Synology will not have the necessary permissions to run the Docker
Compose project.

In the "Schedule" tab pick the schedule that suits your needs.

In the "Task Settings" tab, inside the "User-defined script" text box, paste the following script:

synowebapi --exec api=SYNO.Docker.Project method="start_stream" version=1 id="9fb91ca5-d817-42f8-8ddc-2acdf4d94494"

Note: Replace the id value with the ID you found in the previous step.

That's it! Synology will not start the Project based on the schedule that you provided.

Procrastination Trick - Create Large Pull Requests

Dzhuneyt — Fri, 24 Nov 2023 10:50:17 +0000

I know this is an unpopular opinion: Large PRs are a good way to mask procrastination.

Change my mind. No seriously. I've yet to see a solid example of why bundling many changes in the same PR is a good thing; versus having those changes introduced in smaller PRs.

Is your team suffering from the "Large PRs" syndrome? In my opinion, large PRs are hurtful in many ways:

Lower Code Quality: Due to the complexity and volume of changes in large PRs, there's a higher likelihood of compromising on code quality just to get the PR merged.
Integration Issues: Large PRs often touch multiple parts of the system, which can lead to unexpected integration issues, especially if the changes aren’t properly isolated or modularized.
Increased Merge Conflicts: The longer a PR remains open, the higher the chance of merge conflicts with other changes being merged into the same codebase. Resolving these conflicts can be time-consuming and error-prone.
Knowledge Silos: When a single developer or a small group works on a large set of changes without regular integration, it can lead to knowledge silos, where only a few people understand certain parts of the codebase.
Demotivation and Overwhelm: Reviewers might feel overwhelmed or demotivated by the sheer size of the PR, leading to less effective reviews or reluctance to review at all.
Blocking Other Work: Large PRs can block other work from being merged, especially if they involve core parts of the system that other developers need to work on.
Rollback Complexity: If a problem is discovered after merging a large PR, rolling back the changes can be complex and risky, especially if multiple features or fixes are entangled.
Delaying user value: Large PRs delay delivering small increments of value to the end users, which is at the core of agile software development practices.
Hiding procrastination: Lazy engineers can use large PRs to hide the actual time it took to work on individual parts of the code. Because it's so big, it's difficult to spot periods of procrastination somewhere in the middle. That's why - from an organization perspective - it's important to discourage large PRs.

What size are the Pull Requests in your organization? Can you relate to any of these?

Cut Cloud Costs by Migrating to On-Premises. Is It That Simple?

Dzhuneyt — Tue, 14 Nov 2023 14:38:43 +0000

Let’s imagine you are a Netflix-sized company, and you are paying AWS $1 million per month on Cloud bills. Your app is composed of a bunch of Lambdas behind an API Gateway.

You think $1m per month is too much infrastructure costs.

After spending some engineering effort, you realize that if you re-architect your app into a monolithic container and launch it in a Kubernetes cluster in your on-premises infrastructure, you can run the same app for $100,000 per month — a 10x savings.

Now, you might ask yourself — why is AWS charging you 10 times more? Couldn’t they apply the same optimization that you did, and cascade the cost savings to you as a customer?

The answer is — YES. They could do that.

But they would have to do the same for EVERY SINGLE CUSTOMER of AWS.

Your application and its infrastructure is always unique, to some degree. There are an infinite number of configurations and fine-tuned optimizations that would be needed for every unique customer.

The thing that cloud providers, like AWS, do — is they optimize for common denominators that all customers are interested in — scalability, ease and speed of redeployment, high availability — and finally costs. Cost is one of the factors, but certainly not the most important one for all customers of AWS. Maybe it’s the most important factor for your organization (and that’s fine). But some organizations value more the ease of redeployment and ease of scalability. Every organization is unique and has slightly unique needs.

That’s why you can migrate to On-Premises, fine-tune and optimize better for the factors that are more important to you, whereas AWS will always try to find the middle ground and optimize for the weighted average of all AWS customers’ needs. Not for your organization’s individual needs.

Does your organization fall under the “weighted average customer requirements” segment, or you are more on one side of the amplitude — putting more weight on saving costs?

Migrating from the Cloud to On-Premises infrastructure. Is it worth it?

Dzhuneyt — Tue, 14 Nov 2023 10:27:22 +0000

When a major company shares a case study about saving $1 million annually by moving from AWS cloud to an On-Premises setup, it always grabs the attention of the DevOps community.

It sparks the years-old debates about cloud-native vs. on-premises and Serverless vs. serverfull.

E.g. using on-demand Lambdas and DynamoDB VS always-on Docker containers and PostgreSQL/MySQL, deployed to Kubernetes.

Now, it’s easy to jump on the hype train of the next article that suits your ideology better.

Maybe you have a longer engineering background of developing traditional applications using containers, monolithic applications, and SQL databases — you might be more biased and inclined to support such a Cloud to On-Premises migration.
But if you are coming from the Serverless world, and you prefer the simplicity of NOT managing servers and predictable pricing (pricing that goes hand in hand with usage) — you might be a bit more supportive of the Cloud-native infrastructure. And there’s no right or wrong answer. It’s just engineering perspectives.

A common problem, especially for large organizations, is that such decisions are usually based on this — engineering perspectives, rather than business use cases.

E.g. can the app benefit from the flexible scalability and predictable pricing of being cloud-native? Maybe you should pick that option then. Does it need to be on 24/7 and can’t tolerate cold starts? Maybe an always-on server is the better option here.

And remember — the grass is always greener on the other side. But once you step into the weeds — you quickly realize — that serverless and serverful are both far from perfect options, same as cloud-native and on-premises.

In an ideal world, you would combine the strengths of both sides. So the next time you are thinking of architecture for your app — think about how you can leverage both.

Security: What is "Privilege Escalation"?

Dzhuneyt — Thu, 27 Jul 2023 16:12:15 +0000

Privilege escalation is a common term in the Security industry.

Let's illustrate what it means through an example.

Imagine having a key to your house and you give it temporarily to a plumber, so that they can fix something while you are on vacation.

Your intent is to give temporary access to your house to the plumber. But the locksmith visits a locksmith and makes a copy of the key. Essentially, evading the temporary restriction of accessing your house within a limited timeframe.

The same concept can be applied to software security. It's particularly relevant in Cloud security and giving access to some service to access your Cloud account (e.g. temporary access to assume an IAM role within your AWS account).

If the service is limited to just access resources, but not create new resources - everything is fine and security works as intended. But if the limited access allows the service to create new IAM roles (essentially generate new keys at the locksmith), the service can later access your Cloud resources without your permission. Essentially, doing Privilege Escalation.

AWS EFS Elastic vs Burstable throughput (benchmark)

Dzhuneyt — Thu, 29 Dec 2022 23:19:06 +0000

With the recent announcement of AWS EFS Elastic Throughput mode, I was curious to understand if it's actually any better than the Burstable throughput mode, which I've used as the file storage for a few of my WordPress sites.

I was encountering a few hiccups here and there during WordPress version or plugin upgrades, because of the way the Burstable throughput mode works. Basically as long as your app is not doing any IO operations, the EFS accumulates some burst credits, which are then used during periods of reads/writes, up to a certain limit, after which (when the burst credits are depleted) the EFS read/write operations become painfully slow (at least from my experience).

The announcement of Elastic throughput mode promises that you no longer have to worry about unpredictability of reads/writes to the file system and you should get a pretty consistent performance when using EFS, without resorting to Provisioned throughput mode, which can be pretty expensive due to over-provisioning during prolonged periods of low IO activity.

What better way to evaluate and compare two options than creating a benchmark that does it programmatically for me. Here are the results.

Benchmark results

Writing 10 files, 1KB each

Elastic	Bursting	Time difference
95.2ms	100.6ms	-5.37%

Writing 10 files, 1MB each

Elastic	Bursting	Time difference
366.2ms	369.8ms	-0.97%

Writing 10 files, 100MB each

Elastic	Bursting	Time difference
12.161s	17.081s	-28.80%

Results breakdown

Elastic throughput seems to be completing the write operations faster in all of the benchmarks above, compared to Bursting throughput mode.

For simple sporadic file writes it seems like there is not much of a difference, but Elastic throughput really starts to show its benefits in larger file sizes. Writing 10 files of 100MB can easily save your app 5 seconds of waiting time; savings you can potentially propagate to your end users and improve user experience.

Long story short, I am definitely switching my existing EFS file systems to Elastic throughput mode after these results. The pricing is pretty much the same and there's nothing that stops me from doing the switch at this point.

Of course, don't take my word for it. Do your own due diligence and benchmarks before making a similar switch.

Considerations

The tests were done using an identical Lambda with EFS file system attached
The two Lambdas ran exactly the same code
The numbers above are adjusted to exclude potential side effects like Lambda cold starts, network latency and variability in any surrounding code inside the Lambda runtime. Timestamps are only snapshotted just before and right after the filesystem IO.
Tests are repeated 5 times with a sleep time of 10 seconds in between each run, to give plenty of time for both EFS throughput modes to pick up the pace and trigger any internal caching or warming mechanisms that EFS might have. The results of all 5 test are averaged to come up with the numbers in the benchmark.
Code used to benchmark is available in a GitHub repo

Conclusion

Hope you found this benchmark useful. Looking forward to read your findings in the comments below. You can also catch me at my AWS CDK blog, where you can learn more about corner cases like this or find interesting AWS CDK constructs you can use for your app infrastructure.