Dollar Shave Club is looking for an experienced Go (Golang) engineer interested in Kubernetes, Docker and related infrastructure and security-related projects. Get paid to contribute to OSS and help us build our global e-commerce and fulfillment platform to help men be the best they can be.
Send resume to benjamen@dollarshaveclub.com
That said, Furan isn't suitable for untrusted Dockerfiles (or multi-tenant environments) exactly due to the security implications of access to the Docker engine socket.
The issue I see with Kaniko is drift from upstream Moby/Docker syntax. One of the strengths with Furan is that you have the guarantee that the Docker build you perform locally is exactly what happens by the service. When you can't make this guarantee you get into weird situations where "the build works for me locally" but there's some issue when doing a remote build. That's also why we've resisted putting special build magic into Furan (like injecting metadata into the build context, for example).
- write(2) to STDERR_FILENO
- write(2) to a "self-pipe" (i.e., a pipe where the same
process is waiting on in its event loop), thus turning
the async signal event into an async *I/O* event that
can be handled without any constraints regarding
async-signal-safety
- _exit()
Yes, there are other async-signal-safe functions that can be called from a signal handler, but it's generally not worth it. Adhering to my more constrained approach will keep your code safe and will make it easier to always get it right.ALSO, while we're at it, the only global or thread-local variables you can read from or write to from a signal handler must be of type volatile sig_atomic_t (or else volatile of any other integral or pointer type that you can use with atomic operations). This is very important. E.g., imagine using SIGUSR1/2 to manage verbosity levels...
Want to work on Kubernetes, Docker, GRPC and related ecosystem full-time? Itching to contribute to open source on company time? Do you love distributed systems and solving difficult problems?
DSC is looking for a senior Infrastructure Engineer, experienced in Go and K8s to help us continue to build out systems supporting our international businesses.
We're generally pretty remote-friendly once onboarded, but you will need to be available to be in office when required, so full remote is not an option, unfortunately.
Send CV & GitHub username to benjamen@dollarshaveclub.com. Feel free to reach out with any questions about the role, I'm happy to discuss.
Not true 100% of the time, but it's the right "default" mindset, because it's true the majority of the time.
Deleted Comment
Deleted Comment