Dockerize Airseeker #2
Conversation
There was a problem hiding this comment.
logrotate to rotate logs and cron to start the log rotation.
I am missing the configuration about how the logs are rotated, can you clarify that in README/code?
On interrupt signal, I'm waiting gracefully till the last loops finish instead of killing them forcefully. There's 10s timeout on the pm2 side if they get stuck (that might be set to something higher, not sure how long would one loop takes on average at the moment).
How will this work in practice? I started the airseeker container docker run api3/airseeker (without any options) and I tried to kill it docker kill --signal=INT sweet_chatterjee but it did nothing. When I did docker kill sweet_chatterjee it killed the container immediatelly. Please add (working) commands for this into package.json.
Also, please update the README.
| @@ -0,0 +1 @@ | |||
| 0 2 * * * logrotate -s /app/.pm2/logrotate.status /etc/logrotate.conf | |||
There was a problem hiding this comment.
What is the content of that logrotate.conf file? How do we modify it?
There was a problem hiding this comment.
We don't need to modify it. It's a default file from the logrotate package and the main thing it does is that it is including everything from the '/etc/logrotate.d/ directory where the actual configs are.
There was a problem hiding this comment.
Tbh, I am not ure if having an implicit config for this is a good thing. I'd prefer explicit over implicit. Also, the default config seems to have rention policy for 12 days only whic hseems to me like too little.
There was a problem hiding this comment.
I think it's 12 weeks, not 12 days, the rotating is happening weekly. But I agree that an explicit one is better, I added it to the repository. But I kept the content the same. Let me know if you agree with that.
You're totally right about the signals, I have to rework it a bit. It was working for the interactive mode (with |
src/main.ts
Outdated
| @@ -1 +1,31 @@ | |||
| console.log('main process'); | |||
| const DATA_FETCH_FREQUENCY = 5000; | |||
| const BEACON_UPDATE_FREQUENCY = 10000; | |||
There was a problem hiding this comment.
Nit:
| const BEACON_UPDATE_FREQUENCY = 10000; | |
| const BEACON_UPDATE_FREQUENCY = 10_000; |
I also like appending the unit to the variable name (i.e. _MS) but definitely not super important
| ARG build=local | ||
|
|
||
| # Environment | ||
| FROM node:14.17-alpine3.14 AS environment |
There was a problem hiding this comment.
For what it's worth, we aren't restricted to Node v14 as we are with AWS Lambda. Lambda still doesn't support v16 LTS one year after release 😄
There was a problem hiding this comment.
I haven't thought about that but I guess it would be better to stick to v14 for now just to keep the environments the same. Unless we have some reason (like a feature we want to use) to upgrade.
amarthadan
force-pushed
the
repository-setup
branch
from
9f5b060 to
a722394
Compare
amarthadan
force-pushed
the
dockerization
branch
2 times, most recently
from
fe27d57 to
f7ecf1e
Compare
amarthadan
force-pushed
the
dockerization
branch
from
f7ecf1e to
24654a5
Compare
amarthadan
force-pushed
the
dockerization
branch
from
24654a5 to
1c4dfb0
Compare
| apps: [ | ||
| { | ||
| name: 'airseeker', | ||
| script: './dist/src/main.js', |
There was a problem hiding this comment.
I'm not an expert on pm2 but I found this in the airnode operation package which might be a better alternative. WDYT?
There was a problem hiding this comment.
Do you mean calling ts-node? No, it's not. It's basically the same problem we had when we wanted to dockerize Airkeeper. If we would do it with ts-node we would need to include TypeScript in the Docker image and the start would take longer because the source code needs to be transpiled.
Issue BEC-259
I've decided to use pm2 as process manager, logrotate to rotate logs and cron to start the log rotation.
Only the cron daemon runs under root, both logrotate and pm2 run under non-root user (
airseeker).In
main.tsI'm trying to simulate what the application flow will be - 2 different "loops" (data fetching and beacon updates) running indefinitely in some frequency. On interrupt signal, I'm waiting gracefully till the last loops finish instead of killing them forcefully. There's 10s timeout on the pm2 side if they get stuck (that might be set to something higher, not sure how long would one loop takes on average at the moment).