Docker recently has support for multi stage builds. So you can use one Dockerfile to define how to build your image (produce your jar and necessary other resources) and then copy them into a fresh container running off a more lightweight image that might not contain all the intermediates and your build tools.
> Docker recently has support for multi stage builds.
I view these as a future antipattern. They bring what is properly CI's work inside the Docker daemon, which makes it a larger attack surface (many folks run PRs sight-unseen) and obscures it from outside tooling.
They only exist because of the limits of the Dockerfile format. With something like Jib, that disappears.
Multi-stage builds is definitely my preferred method of building stuff, but the problem I've found is that caching dependencies is bit of a pain, either you need to do some tricks with volumes or your builds will be very slow.
At work, I setup the build system to use Apache Archiva to cache Java dependencies, along with other services like apt-cacher, devpi, and squid, for Debian, Python, and general HTTP caching, respectively. We build all of our images atop the "bitnami/minideb" base, and split the Dockerfiles into "partials" that source a dynamic parent image via a build argument. For example, the partial that sets up Debian package and HTTP caching:
ARG base
FROM ${base}
ARG apt_cacher_host
ARG http_proxy
ARG https_proxy
ARG no_proxy
ENV HTTP_PROXY="${http_proxy}"
ENV HTTPS_PROXY="${https_proxy}"
ENV NO_PROXY="${no_proxy}"
ENV http_proxy="${http_proxy}"
ENV https_proxy="${https_proxy}"
ENV no_proxy="${no_proxy}"
RUN set -ex; \
if [ ! -z "${apt_cacher_host}" ]; then \
echo "Acquire::http::Proxy \"${apt_cacher_host}\";Acquire::https::Proxy \"false\";" >/etc/apt/apt.conf.d/01proxy; \
fi; \
For Java, another partial creates a Maven settings file with the Apache Archiva URL:
ARG base
FROM ${base}
ARG maven_mirror
COPY devops/image-partials/java-artifacts/settings.xml /tmp/settings.xml
RUN set -ex; \
env; \
if [ ! -z "${maven_mirror}" ]; then \
sed -r "s!%%MAVEN_MIRROR%%!${maven_mirror}!g;" /tmp/settings.xml >/usr/share/maven/conf/settings.xml; \
fi;
The important part of settings.xml is this section:
And voila, Maven will go through Archiva for all its dependencies, which are transparently cached so that subsequent builds don't need to re-download everything again.
> "If an application is removed in this way, users will receive a notification on their phone."
The notification is optional (the Market TOS clearly states that they can remove applications without warning)
> And honestly, you're trying to spin the removal of malicious apps as something bad? Really now?
The applications removed were not even malicious (and that's straight from the Android Dev blog), they misrepresented themselves in the description but that's pretty much it.
So clearly, the Android team allows itself to remove not just malicious applications but any and all application from users's handsets.
These applications intentionally misrepresented their purpose in order to encourage user downloads, but they were not designed to be used maliciously, and did not have permission to access private data — or system resources beyond permission.INTERNET. As the applications were practically useless, most users uninstalled the applications shortly after downloading them.
They can remove things, that is the point. Today something bad is malicious software. Tomorrow it will perhaps be depiction of two men kissing or political satire as seen on the iphone, who knows ?
The Android Market has a list of content that is not allowed, including an ambiguous "any material not suitable for persons under 18". And since applications are not individually screened for content, we will see a number of them revoked via this mechanism.
However, note that, unlike the iPhone, Android allows you to install apps from other sources besides the App Market -- sources which are not limited by Google's content policy.
> These applications intentionally misrepresented their purpose in order to encourage user downloads, but they were not designed to be used maliciously, and did not have permission to access private data — or system resources beyond permission.INTERNET.
I can read good sir, but I wasn't talking about that. I do think the application they removed was pretty useless (the experiment it was designed for seemed to be over). What they said is that they removed it in order to test their system, which, according to them, will be used to remove malicious software.
So what's labeled at bad is malicious software. And if I am wrong and the experiment wasn't over, then it just makes my point as it is already (in some meanings of the term) abusive :)
The author voluntarily removed the applications from the Market prior to the remote removals.
I'm having some difficulty making the leap from this incident to being worried about Google removing "any and all applications from the users' handsets". Yes, of course they can. But do we have any basis for worrying that Google will wield this power arbitrarily and in a manner which developers should be concerned about?
Why does the author removing them for the Market justify removing them from handsets?
Just because the developer decides that they don't want to sell (or give away) the app anymore doesn't mean that they should have the power to make that decision retroactive.
I could perhaps see doing it as a sort of nuclear-option security thing; if someone had released an app that made phones overheat or their batteries explode or routed all your phonecalls through Russian Mafia servers. But I'm fairly suspicious that just having this capability will lead to it being used for cases of 'sellers regret'. Or that it might get used if a carrier put enough legal pressure on Google to get rid of something they didn't like. (Hypothetically: something that allowed tethering without paying an additional fee, on carriers that charge extra for it. Or something that allowed VoIP, on carriers that don't allow it. Etc.) The simple fact that the capability exists means that they can be ordered to use it, and I'm not sure I'm comfortable with that, given how easily abused the court system is.
Still, it's better than the iPhone, if only because at least with Android you have the option of installing applications without going through the Market, which are apparently untouchable. It might make me more suspicious about getting anything through the Market that seemed like it might be controversial, though.
https://docs.docker.com/develop/develop-images/multistage-bu...