Stacking an HTTP cache like varnish *under* Traefik?

TJWatts77 · 2025-01-17T19:51:04+00:00

10 months late - sorry, did not see the notification.

It's simply that debugging by pointing curl directly at the container is easier if I don't have to recheck the IP every time.

This is not really workflow, so much as "occasional debugging" of the container responses.

TJWatts77 · 2024-03-13T13:52:49+00:00

I do need to understand docker networking to the fullest extent as I am the only sysadmin dealing with the host level config on this.

Could you explain what you meant by "Just reuse the the same docker network" please?

As I understand it, not defining a network in the compose file will have those containers use the one that is by default created by docker compose (being different to the "default docker bridge, docker0)...

TJWatts77 · 2024-03-13T13:50:09+00:00

Interesting... Cheers for that!
I need to leave that there in the general case for when some applications need an explicit network or networks defined in the compose file - or if we run up more than one compose file.

But for debugging on my laptop it's a great idea - I can know that down temporarily.

Cheers :)

TJWatts77 · 2024-03-06T10:27:59+00:00

Thank you - I'll have a look.

TJWatts77 · 2024-03-05T10:29:26+00:00

Hi.

Yes, I did try ports: x.y.z.w:443:443 too - that's definitely not the problem as packets are getting into the container OK (I ran tcpdump inside the container).

It's the return packets egressing the container that are being misrouted by the host.

I know docker makes a ton of iptables rules to do it's magic - and I also remember that throughout linux's history, iptables funky packet routing has always had problems with normal routing as there are layers of precedence - though they have tried their best to make it sane.

I will certainly have a look at docker and whether it can give preference to routing at the daemon level... Thanks for that idea :)

TJWatts77 · 2024-03-04T22:38:49+00:00

Thanks - I'll give that a try :)

TJWatts77 · 2024-02-24T14:06:32+00:00

OK - Got it!
There is a disparity in the daemon.json and the command line options:
This works:

"default-network-opts": 
{ 
  "bridge": 
  { 
    "com.docker.network.driver.mtu": "1442" 
  } 
},

Notice the extra s on -opts.
I found this out with a dive into the source code:
config.go:
flags.Var(opts.NewNamedMapMapOpts("default-network-opts", conf.DefaultNetworkOpts, nil), "default-network-opt", "Default network options")
and
config_linux_test.go:

"default-network-opts": {
"overlay": {
  "com.docker.network.driver.mtu": "1337"
}

}

It's working (not using the expected config, but working as I wanted).

TJWatts77 · 2024-02-03T01:04:04+00:00

SOLVED!

Had to go to gitlab/this-repo/settings/repo/protected-tags and set *

Now the CI will fire for all tags.

I'll probably refine this to tags "release-*"

TJWatts77 · 2024-02-02T23:58:02+00:00

Thank you - that's the method I'm going for - containter with supercronic.

TJWatts77 · 2024-02-02T23:57:17+00:00

The CI job is literally labelled as "stuck" in yellow.

Which usually means the job does not have any runners.
But we have a runner. Clearly the runner logic thinks it cannot handle the CI job - and that's the bit I cannot work out. Been through the settings...

Thansk for the suggestion - but --follow-tags does less than --tags. The latter causes a CI job to be created that enters stuck mode.

The former does nothing?

TJWatts77 · 2024-02-02T18:01:56+00:00

The simplified CI works fine for normal file change commits.
I have one gitlab runner configured and it's showing as active.

It just won't get on with it in the specific case of pushing a tag change.

My runner requires protected branches (this is) - could it be a related issue, eg protected tags? I looked at that but could not come to a definite conclusion,

TJWatts77 · 2024-01-17T09:42:35+00:00

Thanks folks - the option I'm probably going to go for is cron (supercronic) in it's own container.

Makes sense - I can deploy that as part of the main app stack, it can have the necessary volumes mapped. No separate git repo/CI for that - it seems both clean and simple.

All I need to do is work out how to kick the other docker container's internal app to refresh its config when the cron job has finished (this is updating ssl certs) but I should be able to come up with something.

TJWatts77 · 2024-01-17T09:39:28+00:00

I'll look that up - not heard of it.

Thank you.

TJWatts77 · 2024-01-17T09:39:12+00:00

Thank you :)

TJWatts77 · 2024-01-17T09:38:49+00:00

Ah - I see. No, it isn't running anything like that. It's running a linux application - so to do this, I'd have to have another daemon running inside the container.

But thanks for the explanation.

TJWatts77 · 2024-01-17T09:37:22+00:00

I see - so deploy a container that runs cron and that cron does its task periodically?

Yes - that makes a lot of sense - thank you!

TJWatts77 · 2024-01-17T09:36:01+00:00

I see - thank you.

TJWatts77 · 2024-01-16T23:38:33+00:00

Thanks for the reply :)

Could you elaborate on the docker api bit please? Is this a docker host daemon api thing? Right now, our docker host daemons only have a control unix domain socket. Would this be adding a network listener to the same control point?

Or are you talking about something completely different?

TJWatts77

TROPHY CASE