Avoiding redundant container builds
vonsnowman.com2 pointsby vonsnowman0 comments
- golang-builder does not provide a convenient script, instead requiring manual
docker invocations [more flexible but more cumbersome]
- golang-builder uses volumes, which makes it very hard to use within a container
[may not matter to everyone but it certainly does to us]
- golang-builder uses a significantly larger base image
- gockerize has a really nice logo ;) 1. the JVM itself imposes a high floor (hotspot, many shared libs loaded, ...)
2. the Java language is full of overhead at every level (boxed types are a pet peeve of mine)
3. the Java ecosystem has a tendency to regard memory as an inexhaustible resource, which lead a lot of waste in many 3rd party libraries
The core point is that optimizing this particular Java program (and the others that followed) would have been more time-consuming than a Golang rewrite and would have probably increased the complexity whereas a Golang rewrite reduced it. - team-server probe: already mentioned in the blog post.
Determines if any installed Team Server is down.
- ca: as mentioned in the blog post, as simple Certificate Authority
- charlie: a checkin service. Desktop clients periodically post to it
to signify they are up. This data is used in each user's device list
to show if the device is up and which ip it was last seen from.
- auditor: takes audit event in an HTTP endpoint and forwards
them to a raw TCP connection as expected by splunk and co
- valkyrie: a relay server used for data transfers when desktop
clients cannot establish direct TCP connection (more about that
in a future blog post)
- lipwig: a messaging/pubsub server used for peer discovery
and notifications (more about that in a future blog post)