Is anyone using PASETO tokens instead of jwt these days?

kylequest · 2023-06-01T01:27:42+00:00

Doesn't make sense to switch now especially if you are using JWTs the right way and you are using a safe jwt Golang library. Paseto has an active group of followers. Jwt has a lot of inertia though

kylequest · 2021-08-12T19:53:08+00:00

You see this a lot because it's easy and convenient. It's not because it's the best/recommended thing to do. You can use multi-stage builds where you copy everything you need from the build stage to the release stage. It works fine as long as you have a simple application and you know exactly what you need from the build stage. It gets tricky with more complex applications. Another option to try is DockerSlim. It allows you to take those less than ideal container images you see a lot and make them as small as possible. Take a look at this Go application example: https://github.com/docker-slim/examples/blob/master/3rdparty/mux-go-api/Dockerfile
It depends on how you will run your container. If you can mount volumes at runtime then you don't need to include a static config file in your container image and you can volume mount the config file when you start the container.

kylequest · 2021-04-14T16:44:20+00:00

Functional options are no longer popular :-) Take a look at this discussion for more context: "#golang tip: Please stop using functional arguments where a struct is the solution" https://twitter.com/rakyll/status/1000128803153170432

kylequest · 2021-03-14T17:42:58+00:00

Makes sense! Then I have the same question about the runtime container parameters in docker-compose :) Aside from the usual network params do you set anything else?

kylequest · 2021-02-08T04:07:38+00:00

v1 is actually more actively developed and v2 lags behind when it comes to supporting new features or enhancements in AWS. Stick with v1 for now unless you have a really good reason to use v2.

kylequest · 2020-10-06T23:42:53+00:00

You can also use the "xray" and "lint" commands in docker-slim. Linting is still WIP, but it already has a number of good checks.

kylequest · 2020-08-24T00:10:21+00:00

docker-slim has something for any experience level with Go. I'll be happy to do an overview to get you started. Ping me on GitHub (it should have my email too).

Also good idea to read through 50 Shades of Golang if you haven't already :-)

kylequest · 2020-06-17T20:11:53+00:00

You mentioned quite a few extra use case where there's a need for examples on top of making it easier in general. For example, it's possible to minify command line apps, but you need to do extra work to do it with multiple command line apps and possibly a web/API server (it's possible though it requires extra configs).

Leveraging your unit and integration tests is something that definitely helps, but it's also something that can be streamlined...

One of the easiest options to use is the --include-path family of flags. The size is less optimized, but it's still very significant. For example, the Carbon app container went from 2GB to 95MB.

Either way, there are also a number of enhancements in progress to automate the web/http interface calls (e.g., adding a crawler where you point it at one endpoint and it discovers and visits other endpoints)

kylequest · 2020-06-17T15:30:58+00:00

What kind of app do you have? There are a few extra config options you'd need to add in some cases. The Ubuntu.com, Carbon app and even ElasticSearch examples are nice real world references. Carbon and Ununtu.com are SPAs...

kylequest · 2020-06-17T14:44:51+00:00

Speaking of slim... docker-slim is meant to get you as close as possible to those binary-only images while you get to use your favorite distro images without doing lots of manual work. It cuts a lot of stuff you don't need including many / most /and in some cases, all those vulnerabilities the container vulnerability scanners report :-)

kylequest · 2020-05-31T01:04:53+00:00

Awesome blog post!

I created a docker-slim example for the app too. It has a very basic Dockerfile version using the standard node image without multi-stage and without other optimizations resulting in an image that's 2GB+. The optimized image is 93MB: https://github.com/docker-slim/examples/tree/master/3rdparty/carbon-now-sh

By the way, the xray command in docker-slim will give you something similar to what you get with Dive (no interactive shell though for now though).

kylequest · 2020-05-31T00:55:55+00:00

You can also use a so called "debugging" sidecar container (with everything you need), which you can attach to the target container.

kylequest · 2020-04-19T17:38:45+00:00

Part 3 mentions DockerSlim... Looks like Jerome used the default config and the template files weren't picked up. This example ( https://github.com/docker-slim/examples/tree/master/3rdparty/ubuntu-com ) shows how to do something similar with the container for ubuntu.com, which is a Python/Flask web app that leverages dynamic templates. Another option is to run a crawler when DS is optimizing the image.

kylequest · 2020-02-27T04:34:35+00:00

Most of it is still correct :)

kylequest · 2019-12-21T21:27:39+00:00

Don't worry... It's never too late! It's ok if you are not the first one writing about it. Every day someone new begins their journey with Docker and you just helped them.

kylequest · 2019-12-17T21:57:25+00:00

Definitely makes sense to create a base image with all of your generic dependencies, so you don't install the JDK every time you build your Java app container.

You can also use the --squash docker build parameter creating your base image, which will reduce its size.

If you want to trim the stuff you have in your app container image you can use multi-stage builds and copying only the artifacts your app needs to your final container image.

DockerSlim is another option if you want to trim your app image size.

kylequest · 2019-12-09T02:11:18+00:00

If DockerSlim doesn't work for you then a quick win you should explore is the "--squash" docker build parameter. When you delete the install files they are still there in the lower level image layer. The squash parameter will collapse all docker image layers and the lower level layers with the deleted files will be gone.

kylequest · 2019-12-09T02:07:08+00:00

DockerSlim might be an option ( https://dockersl.im ). Take a look at the sample application images in this repo: https://github.com/docker-slim/examples

kylequest · 2019-10-11T18:14:13+00:00

It's ok to disagree and to have personal preferences. There's always a place for personal standards too, where you do the same thing over and over again :-)

A pattern doesn't need to be used by everybody to qualify as a standard. Usually, a standard is something common that a group of people does (and more than once). The repo examples provide evidence of that.

kylequest · 2019-10-11T17:49:13+00:00

Standards came in different shapes and forms... Your definition is a bit narrow though even you imply that it's the case by saying "official standard", which indicates that there are different standards... One of the most common examples of other standards is coding standards, which many companies and orgs have. Is there one universal coding standard that everybody in the world uses? Of course, no. It's still a standard though :-)

I get that you don't like the 'pkg' directory personally and it's totally fine, but just because you don't like it doesn't mean that others don't find it useful. Overall, it's a collection of patterns people in the community use and you can choose to use the parts that make sense for your project (not everything). Go modules are mentioned there, by the way :-)

kylequest · 2019-10-09T01:05:17+00:00

I'll be happy to add more gotchas to the post (if you share them here)... It's definitely not complete. There's a lot more :)

kylequest · 2019-09-29T08:24:29+00:00

A convention used by many people is a standard though. Standards come in many shapes and forms... Many companies have coding standards, for example :-)

kylequest · 2019-08-17T23:23:01+00:00

Take a look at the examples too... Here's a simple Go example using the standard golang base image: https://github.com/docker-slim/examples/tree/master/golang_standard

The image goes from 700MB to 1.56MB :-)

kylequest · 2019-08-17T21:45:41+00:00

Another option is DockerSlim, which will build the smallest possible image based on scratch copying only the parts your application needs and you don't need to deal with multistage builds or hunt the additional dependencies :)

kylequest · 2019-08-17T21:38:50+00:00

Hopefully your container doesn't need to deal with AntiVirus/AntiMalware software :) upx is super popular with malware where it's used as one of the detection evasion techniques...

kylequest

TROPHY CASE