- This document originated from a bunch of most commonly used links and learning resources I sent to every new web developer on our full-stack web development team.
- For each problem domain and each technology, I try my best to pick only one or a few links that are most important, typical, common or popular and not outdated, base on the clear trends, public data and empirical observation.
- Prefer fine-grained classifications and deep hierarchies over featureless descriptions and distractive comments.
- Ideally, each line is a unique category. The ” / “ symbol between the links means they are replaceable. The “, “symbol between the links means they are complementary.
- I wish this document could be closer to a kind of knowledge graph or skill tree than a list or a collection.
- It currently contains 2000+ links (projects, tools, plugins, services, articles, books, sites, etc.)
On one hand, this is one of the best single resources on the topic of web development that I’ve seen in a very long time. On the other hand, it re-confirms my belief in “there is no such thing as a full-stack web developer”. There’s just too many levels, and there’s too much depth to each level for a single individual to be an expert at. But you get bonus points for trying.
Docker Blog is introducing the Moby Project:
The Moby Project is a new open-source project to advance the software containerization movement and help the ecosystem take containers mainstream. It provides a library of components, a framework for assembling them into custom container-based systems and a place for all container enthusiasts to experiment and exchange ideas.
This just had to happen, given the nature of the Open Source and the importance of the container technology for the modern infrastructure.
Here are some exciting news from the BitBucket Pipelines blog: Bitbucket Pipelines now supports building Docker images, and service containers for database testing.
We developed Pipelines to enable teams to test and deploy software faster, using Docker containers to manage their build environment. Now we’re adding advanced Docker support – building Docker images, and Service containers for database testing.
Federacy has an interesting research in Docker image vulnerabilities. The bottom line is:
24% of latest Docker images have significant vulnerabilities
This can and should be improved, especially given the whole hierarchical structure of Docker images. It’s not like improving security of all those random GitHub repositories.
Jessie Frazelle reiterates her point on containers in the blog post “Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs“:
The Design of Solaris Zones, BSD Jails, VMs and containers are very different.
Solaris Zones, BSD Jails, and VMs are first class concepts. This is clear from the Solaris Zone Design Spec and the BSD Jails Handbook. I hope it can go without saying that VMs are very much a first class object without me having to link you somewhere :P.
Containers on the other hand are not real things.
A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers.
10 things to avoid in Docker containers provides a handy reminder of what NOT to do when building Docker containers. Read the full article for details and explanations. For a brief summary, here are the 10 things:
- Don’t store data in containers
- Don’t ship your application in two pieces
- Don’t create large images
- Don’t use a single layer image
- Don’t create images from running containers
- Don’t use only the “latest” tag
- Don’t run more than one process in a single container
- Don’t store credentials in the image. Use environment variables
- Don’t run processes as a root user
- Don’t rely on IP addresses
I’ve been meaning to look into Docker for a long while now. But, as always, time is the issue. In the last couple of days though I’ve been integrating BitBucket Pipelines into our workflow. BitBucket Pipelines is a continuous integration solution, which runs your project tests in a Docker container. So, naturally, I had to get a better idea of how the whole thing works.
“Docker for PHP Developers” article was super useful. Even though it wasn’t immediately applicable to BitBucket Pipelines, as they don’t currently support multiple containers – everything has to run within a single container.
The default BitBucket Pipelines configuration suggests the phpunit/phpunit image. If you want to run PHPUnit tests only, that works fine. But if you want to have a full blown Nginx and MySQL setup for extra bits (UI tests, integration tests, etc), then you might find smartapps/bitbucket-pipelines-php-mysql image much more useful. Here’s the full bitbucket-pipelines.yml file that I’ve ended up with.
There is this discussion over at StackOverflow: Should I use Vagrant or Docker for creating an isolated environment? It attracted the attention of the authors of both projects (as well as many other smart people). Read the whole thing for interesting insights into what’s there now and what’s coming. If you’d rather have a summary, here it is:
The short answer is that if you want to manage machines, you should use Vagrant. And if you want to build and run applications environments, you should use Docker.
Serverlessconf 2016 – New York City: a personal report – is a fascinating read. Let me get you hooked:
This event left me with the impression (or the confirmation) that there are two paces and speeds at which people are moving.
There is the so called “legacy” pace. This is often characterized by the notion of VMs and virtualization. This market is typically on-prem, owned by VMware and where the majority of workloads (as of today) are running. Very steady.
The second “industry block” is the “new stuff” and this is a truly moving target. #Serverless is yet another model that we are seeing emerging in the last few years. We have moved from Cloud (i.e. IaaS) to opinionated PaaS, to un-opinionated PaaS, to DIY Containers, to CaaS (Containers as a Service) to now #Serverless. There is no way this is going to be the end of it as it’s a frenetic moving target and in every iteration more and more people will be left behind.
This time around was all about the DevOps people being “industry dinosaurs”. So if you are a DevOps persona, know you are legacy already.
Sometimes I feel like I am leaving on a different planet. All these people are so close, yet so far away …
With the recent explosion in the virtualization and container technologies, one is often left disoriented. Questions like “should I use virtual machines or containers?”, “which technology should I use”, and “can I migrate from one to another later?” are just some of those that will need answering.
Here is an open source tool that helps to avoid a few of those questions – Packer (by HashiCorp):
Packer is a tool for creating machine and container images for multiple platforms from a single source configuration.
Have a look at the supported platforms:
- Amazon EC2 (AMI). Both EBS-backed and instance-store AMIs within EC2, optionally distributed to multiple regions.
- DigitalOcean. Snapshots for DigitalOcean that can be used to start a pre-configured DigitalOcean instance of any size.
- Docker. Snapshots for Docker that can be used to start a pre-configured Docker instance.
- Google Compute Engine. Snapshots for Google Compute Engine that can be used to start a pre-configured Google Compute Engine instance.
- OpenStack. Images for OpenStack that can be used to start pre-configured OpenStack servers.
- Parallels (PVM). Exported virtual machines for Parallels, including virtual machine metadata such as RAM, CPUs, etc. These virtual machines are portable and can be started on any platform Parallels runs on.
- QEMU. Images for KVM or Xen that can be used to start pre-configured KVM or Xen instances.
- VirtualBox (OVF). Exported virtual machines for VirtualBox, including virtual machine metadata such as RAM, CPUs, etc. These virtual machines are portable and can be started on any platform VirtualBox runs on.
- VMware (VMX). Exported virtual machines for VMware that can be run within any desktop products such as Fusion, Player, or Workstation, as well as server products such as vSphere.
The only question remaining now, it seems, is “why wouldn’t you use it?”. :)