Talk to us
+
+
Talk to us
+
-
-
- Follow @moby to get the latest news and project updates
-
-
+
Join our community Slack channel to learn, mentor and collaborate with maintainers and members of the Moby community
- 
@@ -18,7 +11,7 @@
+
Check out the project on GitHub and get involved as a contributor
-
+
-
-
-
+
\ No newline at end of file
diff --git a/src/moby-summit-june.md b/src/moby-summit-june.md
deleted file mode 100644
index 0ebf9a5..0000000
--- a/src/moby-summit-june.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Moby Summit June 2017
-layout: default
----
-
-### Moby Summit 6/19/17
-
-The Moby Summit is a small collaborative event taking place on **Monday 6/19/17 at Docker HQ in San Francisco**. This summit is for advanced container users who are actively maintaining, contributing or generally involved in the design and development of the Moby Project and it's components: LinuxKit, Infrakit, SwarmKit, HyperKit, DataKit, VPNKit, Notary, libnetwork, etc.
-
-This will be a great opportunity for everyone attending the summit to learn, hack, collaborate and give feedback to drive the architectural decisions and roadmap behind the moby project and it's components.
-
-Here is the link to register for the event: https://www.eventbrite.com/e/moby-summit-tickets-34483396768
-
-Thanks, and looking forward to seeing you there!
-
-Follow [this link to register](https://www.eventbrite.com/e/moby-summit-tickets-34483396768)!
-
-All revenue from ticket sales will be donated to a non-profit organization promoting diversity in the tech industry.
-
-
-
-## Agenda (subject to Change)
-
-8:00am - 9:00am - Registration & Breakfast
-
-9am - 9:15am - Opening words by Solomon Hykes
-
-9:15am - 9:45am - LinuxKit
-
-9:45am - 10:15am - containerd
-
-10:15am - 10:30am - Break
-
-10:30am - 11:00am - Infrakit
-
-11:00 - 11:15am - SwarmKit / Libnetwork
-
-11:15pm - 12:15pm - Security (Notary, Secrets, Image scanning)
-
-12:15 - 1:15pm - Lunch
-
-1:15pm - 2:45pm - Birds of a feather part 1
-
-2:45 - 3:00pm - Break
-
-3:00pm - 4:30pm - Birds of a feather part 2
-
-4:30pm - 5:00pm - BOFs recap + AMA / panel
-
-5:00 - 7:00pm - Happy Hour
diff --git a/src/projects.md b/src/projects.md
index 7a38f68..2bf08cf 100644
--- a/src/projects.md
+++ b/src/projects.md
@@ -9,28 +9,7 @@ Moby is an open-source project, created by Docker, to enable and accelerate soft
-The projects themselves provide a "Lego set" of toolkit components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts and professionals to experiment and exchange ideas. There is a Technical Steering committee, elected by the projects, to help with project governance.
-
-
- -### Technical Steering Committee - -The Technical Steering Committee acts as an escalation point for conflicts within projects, encourages cross-project communication and coordination, as well as helping with project governance. The TSC is not involved in the day-to-day activities of the projects but can resolve technical disputes when an issue has been escalated to the committee. - -Seats on the committee are allocated by election and seats are held for a fixed term. You can read more about the Technical Steering Committee, including the list of [current members](https://github.com/moby/tsc/blob/master/MEMBERS.md), over on the [TSC repository](https://github.com/moby/tsc). - -
- -### Moby Special Interest Groups - -Moby Project also hosts Special Interest Groups (SIG) for discussing subtopics among interested contributors. SIGs typically meet every week and post their meeting minutes and video of the meetings online. If you're interested in starting a SIG, please begin a discussion on the [forum](https://forums.mobyproject.org). - -**Current SIGs** - -| Name | Leads | Agenda | Forum | Meetings | -|------|-------|--------|-------|----------| -| [LinuxKit Security](https://github.com/linuxkit/linuxkit/tree/master/sigs/security) | [@riyazdf](https://github.com/riyazdf) Riyaz Faizullabhoy | [Agenda and Meeting Notes](https://github.com/linuxkit/linuxkit/tree/master/reports/sig-security) | [Forum](https://forums.mobyproject.org/c/sig/linuxkit-security) | [Every other Wednesday at 9:00 AM PST](https://docker.zoom.us/j/779801882) | -| [Orchestration Security](https://github.com/docker/swarmkit/tree/master/sigs/orchestration-security) | [@diogomonica](https://github.com/diogomonica) Diogo Monica | [Agenda and Meeting Notes](https://docs.google.com/document/d/1co6Jv9Mq8jeToK-sYNNXwUQiPWcDCvlNJ5bozAOfriE/edit) | [Forum](https://forums.mobyproject.org/c/sig/orchestration-security) | [Every other Tuesday at 3:00 PM PST](https://docker.zoom.us/j/417366441) | +The projects themselves provide a "Lego set" of toolkit components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts and professionals to experiment and exchange ideas.
diff --git a/src/_layouts/blog.html b/src/_layouts/blog.html
deleted file mode 100644
index 6b8b4c3..0000000
--- a/src/_layouts/blog.html
+++ /dev/null
@@ -1,15 +0,0 @@
-{% include head.html %}
-
-{% include header-sm.html %}
-
-
-
-
-
-
-
-{% include footer.html %}
diff --git a/src/_scss/ _blog.scss b/src/_scss/ _blog.scss
deleted file mode 100644
index e69de29..0000000
diff --git a/src/blog/_posts/2017-05-01-moby-builder-report.md b/src/blog/_posts/2017-05-01-moby-builder-report.md
deleted file mode 100644
index c62b0e4..0000000
--- a/src/blog/_posts/2017-05-01-moby-builder-report.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Moby Builder Report 2017-05-01
-layout: post
-author: Moby Dev Team
-author-url: https://github.com/moby/moby/blob/4f3c5b2568c28a4e0fd1b69ec6f2e0a0715d8cf5/reports/builder/2017-05-01.md
-excerpt_separator:
----
-
-## buildkit
-
-As part of the goals of [Moby](https://github.com/moby/moby#transitioning-to-moby) to split the current platform into reusable components and to provide a future vision for the builder component new [buildkit proposal](https://github.com/moby/moby/issues/32925) was opened with early design draft.
-
-
-Buildkit is a library providing the core essentials of running a build process using isolated sandboxed commands. It is designed for extensibility and customization. Buildkit supports multiple build declaration formats(frontends) and multiple ways for outputting build results(not just docker images). It doesn't make decisions for a specific worker, snapshot or exporter implementations.
-
-It is designed to help find the most efficient way to process build tasks and intelligently cache them for repeated invocations.
-
-### Quality: Dependency interface switch
-
-To improve quality and performance, a new [proposal was made for switching the dependency interface](https://github.com/moby/moby/issues/32904) for current builder package. That should fix the current problems with data leakage and conflicts caused by daemon state cleanup scripts.
-
-@dnephin is in progress of refactoring current builder code to logical areas as a preparation work for updating this interface.
-
-Merged as part of this effort:
-
-- [Refactor Dockerfile.parser and directive](https://github.com/moby/moby/pull/32580)
-- [Refactor builder dispatch state](https://github.com/moby/moby/pull/32600)
-- [Use a bytes.Buffer for shell_words string concat](https://github.com/moby/moby/pull/32601)
-- [Refactor `Builder.commit()`](https://github.com/moby/moby/pull/32772)
-- [Remove b.escapeToken, create ShellLex](https://github.com/moby/moby/pull/32858)
-
-### New feature: Long running session
-
-PR for [adding long-running session between daemon and cli](https://github.com/moby/moby/pull/32677) that enabled advanced features like incremental context send, build credentials from the client, ssh forwarding etc. is looking for initial design review. It is currently open if features implemented on top of it would use a specific transport implementation on the wire or a generic interface(current implementation). @tonistiigi is working on adding persistent cache capabilities that are currently missing from that PR. It also needs to be figured out how the [cli split](https://github.com/moby/moby/pull/32694) will affect features like this.
-
-### Proposals for new Dockerfile features that need design feedback:
-
-[Add IMPORT/EXPORT commands to Dockerfile](https://github.com/moby/moby/issues/32100)
-
-[Add `DOCKEROS/DOCKERARCH` default ARG to Dockerfile](https://github.com/moby/moby/issues/32487)
-
-[Add support for `RUN --mount`](https://github.com/moby/moby/issues/32507)
-
-These proposals have gotten mostly positive feedback for now. We will leave them open for a couple of more weeks and then decide what actions to take in a maintainers meeting. Also, if you are interested in implementing any of them, leave a comment on the specific issues.
-
-### Other new builder features currently in code-review:
-
-[`docker build --iidfile` to capture the ID of the build result](https://github.com/moby/moby/pull/32406)
-
-[Allow builds from any git remote ref](https://github.com/moby/moby/pull/32502)
-
-### Backlog:
-
-[Build secrets](https://github.com/moby/moby/pull/30637) will be brought up again in next maintainer's meeting to evaluate how to move on with this, if any other proposals have changed the objective and if we should wait for swarm secrets to be available first.
\ No newline at end of file
diff --git a/src/blog/_posts/2017-05-01-moby-dev-report.md b/src/blog/_posts/2017-05-01-moby-dev-report.md
deleted file mode 100644
index 390c6a7..0000000
--- a/src/blog/_posts/2017-05-01-moby-dev-report.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Moby Dev Report 2017-05-01
-layout: post
-author: Moby Dev Team
-author-url: https://github.com/moby/moby/blob/4f3c5b2568c28a4e0fd1b69ec6f2e0a0715d8cf5/reports/2017-05-01.md
-excerpt_separator:
----
-
-## Moby Dev Report
-
-This is the 1st report, since the Moby project was announced at DockerCon. Thank you to everyone that stayed an extra day to attend the summit on Thursday.
-
-## Daily Meeting
-
-A daily meeting is hosted on [slack](dockercommunity.slack.com) every business day at 9am PST on the channel `#moby-project`.
-During this meeting, we are talking about the [tasks](https://github.com/moby/moby/issues/32867) needed to be done for splitting moby and docker.
-
-## Topics discussed last week
-
-### The moby tool
-
-The moby tool currently lives at [https://github.com/moby/tool](https://github.com/moby/tool), it's only a temporary place and will soon be merged in [https://github.com/moby/moby](https://github.com/moby/moby).
-
-### The CLI split
-
-Ongoing work to split the Docker CLI into [https://github.com/docker/cli](https://github.com/docker/cli) is happening [here](https://github.com/moby/moby/pull/32694).
-We are almost done, it should be merged soon.
-
-### Mailing list
-
-Slack works great for synchronous communication, but we need to place for async discussion. A mailing list is currently being setup.
-
-#### Find a good and non-confusing home for the remaining monolith
-
-Lots of discussion and progress made on this topic, see [here](https://github.com/moby/moby/issues/32871). The work will start this week.
-
-## Componentization
-
-So far only work on the builder happened regarding the componentization effort.
diff --git a/src/blog/_posts/2017-05-04-moby-blog.md b/src/blog/_posts/2017-05-04-moby-blog.md
deleted file mode 100644
index 68c3ba9..0000000
--- a/src/blog/_posts/2017-05-04-moby-blog.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: The Moby Project Blog
-layout: post
-author: Amir Chaudhry
-author-url: https://twitter.com/amirmc
-published: false
----
-
-Welcome to the Moby blog!
\ No newline at end of file
diff --git a/src/blog/_posts/2017-05-08-moby-builder-report.md b/src/blog/_posts/2017-05-08-moby-builder-report.md
deleted file mode 100644
index 78e754a..0000000
--- a/src/blog/_posts/2017-05-08-moby-builder-report.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Moby Builder Report 2017-05-08
-layout: post
-author: Moby Dev Team
-author-url: https://github.com/moby/moby/blob/4f3c5b2568c28a4e0fd1b69ec6f2e0a0715d8cf5/reports/builder/2017-05-08.md
-excerpt_separator:
----
-
-## Quality: Dependency interface switch
-
-Proposal for [switching the dependency interface](https://github.com/moby/moby/issues/32904) for current builder package. That should fix the current problems with data leakage and conflicts caused by daemon state cleanup scripts.
-
-Merged as part of this effort:
-
-- [Move dispatch state to a new struct](https://github.com/moby/moby/pull/32952)
-- [Cleanup unnecessary mutate then revert of b.runConfig](https://github.com/moby/moby/pull/32773)
-
-In review:
-- [Refactor builder probe cache and container backend](https://github.com/moby/moby/pull/33061)
-- [Expose GetImage interface for builder](https://github.com/moby/moby/pull/33054)
-
-### Merged: docker build --iidfile
-
-[`docker build --iidfile` to capture the ID of the build result](https://github.com/moby/moby/pull/32406). New option can be used by the CLI applications to get back the image ID of build result. API users can use the `Aux` messages in progress stream to also get the IDs for intermediate build stages, for example to share them for build cache.
-
-### New feature: Long running session
-
-PR for [adding long-running session between daemon and cli](https://github.com/moby/moby/pull/32677) that enables advanced features like incremental context send, build credentials from the client, ssh forwarding etc.
-
-@simonferquel proposed a [grpc-only version of that interface](https://github.com/moby/moby/pull/33047) that should simplify the setup needed for describing new features for the session. Looking for design reviews.
-
-The feature also needs to be reworked after CLI split.
-
-### buildkit
-
-Not much progress [apart from some design discussion](https://github.com/moby/moby/issues/32925). Next step would be to open up a repo.
-
-### Proposals for new Dockerfile features that need design feedback:
-
-[Add IMPORT/EXPORT commands to Dockerfile](https://github.com/moby/moby/issues/32100)
-
-[Add `DOCKEROS/DOCKERARCH` default ARG to Dockerfile](https://github.com/moby/moby/issues/32487)
-
-[Add support for `RUN --mount`](https://github.com/moby/moby/issues/32507)
-
-[DAG image builder](https://github.com/moby/moby/issues/32550)
-
-[Option to export the hash of the build context](https://github.com/moby/moby/issues/32963) (new)
-
-[Allow --cache-from=*](https://github.com/moby/moby/issues/33002#issuecomment-299041162) (new)
-
-If you are interested in implementing any of them, leave a comment on the specific issues.
-
-### Other new builder features currently in code-review:
-
-[Allow builds from any git remote ref](https://github.com/moby/moby/pull/32502)
-
-[Fix a case where using FROM scratch as NAME would fail](https://github.com/moby/moby/pull/32997)
-
-### Backlog:
-
-[Build secrets](https://github.com/moby/moby/pull/30637) will be brought up again in next maintainer's meeting to evaluate how to move on with this, if any other proposals have changed the objective and if we should wait for swarm secrets to be available first.
diff --git a/src/blog/_posts/2017-05-08-moby-dev-report.md b/src/blog/_posts/2017-05-08-moby-dev-report.md
deleted file mode 100644
index 5a827f5..0000000
--- a/src/blog/_posts/2017-05-08-moby-dev-report.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Moby Dev Report 2017-05-08
-layout: post
-author: Moby Dev Team
-author-url: https://github.com/moby/moby/blob/4f3c5b2568c28a4e0fd1b69ec6f2e0a0715d8cf5/reports/2017-05-08.md
-excerpt_separator:
----
-
-## Daily Meeting
-
-A daily meeting is hosted on [slack](https://dockercommunity.slack.com) every business day at 9am PST on the channel `#moby-project`.
-During this meeting, we are talking about the [tasks](https://github.com/moby/moby/issues/32867) needed to be done for splitting moby and docker.
-
-## Topics discussed last week
-
-### The CLI split
-
-The Docker CLI was succesfully moved to [https://github.com/docker/cli](https://github.com/docker/cli) last week thanks to @tiborvass
-The Docker CLI is now compiled from the [Dockerfile](https://github.com/moby/moby/blob/a762ceace4e8c1c7ce4fb582789af9d8074be3e1/Dockerfile#L248)
-
-### Mailing list
-
-Discourse is available at [forums.mobyproject.org](https://forums.mobyproject.org/) thanks to @thaJeztah. mailing-list mode is enabled, so once you register there, you will received every new threads / messages via email. So far, 3 categories were created: Architecture, Meta & Support. The last step missing is to setup an email address to be able to start a new thread via email.
-
-### Find a place for `/pkg`
-
-Lots of discussion and progress made on this [topic](https://github.com/moby/moby/issues/32989) thanks to @dnephin. [Here is the list](https://gist.github.com/dnephin/35dc10f6b6b7017f058a71908b301d38) proposed to split/reorganize the pkgs.
-
-### Find a good and non-confusing home for the remaining monolith
-
-@cpuguy83 is leading the effort [here](https://github.com/moby/moby/pull/33022). It's still WIP but the way we are experimenting with is to reorganise directories within the moby/moby.
-
-## Componentization
-
-So far only work on the builder, by @tonistiigi, happened regarding the componentization effort.
diff --git a/src/blog/_posts/2017-05-11-moby-summit-report.md b/src/blog/_posts/2017-05-11-moby-summit-report.md
deleted file mode 100644
index 9db9859..0000000
--- a/src/blog/_posts/2017-05-11-moby-summit-report.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Moby Summit at DockerCon 2017-05-11
-layout: post
-author: Victor Coisne
-author-url:
-excerpt_separator:
----
-
-## Moby Summit videos from DockerCon
-
-Last month at DockerCon, Solomon introduced the [Moby Project: a new open-source project to advance the software containerization movement](https://blog.docker.com/2017/04/introducing-the-moby-project/). The idea behind the project is to help the ecosystem take containers mainstream by providing 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. Going forward, Docker will be assembled using Moby, see [Moby and Docker](http://mobyproject.org/#moby-and-docker) or the diagram below for more details.
-
-
-
-Knowing that that a good number of maintainers, contributors and advanced Docker users would be attending DockerCon, we decided to organize the first Moby Summit in collaboration with the Cloud Native Computing Foundation (CNCF). The summit was a small collaborative event for container hackers who are actively maintaining, contributing or generally involved or interested in the design and development of components of the Moby project library in particular: [LinuxKit](https://github.com/linuxkit/linuxkit), [containerd](https://github.com/containerd), [Infrakit](https://github.com/docker/infrakit), [SwarmKit](https://github.com/docker/swarmkit), [libnetwork](https://github.com/docker/libnetwork) and [Notary](https://github.com/docker/notary)
-
-Here’s what we covered during the first part of the summit:
-
-- [0:05](https://youtu.be/-C_YL6za0-E?t=5s) - Opening words by Patrick Chanezon
-
-- [9:05](https://youtu.be/-C_YL6za0-E?t=9m6s) - Moby Project Q&A with Solomon Hykes and Justin Cormack
-
-- [60:14](https://youtu.be/-C_YL6za0-E?t=1h14m32s) - Quick update on containerd by Michael Crosby
-
-Here’s what we covered during the 2nd part of the summit:
-
-- [0:18](https://youtu.be/Raj0zaqBxOc?t=18s) - Swarmkit update by Andrea Luzzardi
-
-- [7:52](https://youtu.be/Raj0zaqBxOc?t=7m52s) - Libnetwork update by Madhu Venugopal
-
-- [16:27](https://youtu.be/Raj0zaqBxOc?t=16m27s) - Notary update by David Lawrence
-
-- [19:59](https://youtu.be/Raj0zaqBxOc?t=19m59s) - InfraKit update by David Chung
-
-- [36:39](https://youtu.be/Raj0zaqBxOc?t=36m39s)- Infinit update by Julien Quintard
-
-- [49:09](https://youtu.be/Raj0zaqBxOc?t=49m9s) - MirageOS by Mindy Preston
-
-The 3rd part of the summit consisted in birds of feather session around each components of the Moby Project library. This was a perfect opportunity for maintainers and contributors to discuss open issues, pull requests and roadmap as you can see below.
-
-
-Learn more about the Moby Project:
-
-- Follow [@moby on twitter](https://twitter.com/moby)
-
-- Register for the next [Moby Summit](https://www.eventbrite.com/e/moby-summit-tickets-34483396768) at Docker HQ on 6/19
-
-- Join the conversation on [Slack #Moby-project](dockr.ly/community)
diff --git a/src/blog/_posts/2017-06-26-moby-summit-recap.md b/src/blog/_posts/2017-06-26-moby-summit-recap.md
deleted file mode 100644
index 33e102b..0000000
--- a/src/blog/_posts/2017-06-26-moby-summit-recap.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Moby Summit June 2017 Recap
-layout: post
-author: Patrick Chanezon
-author-url: https://twitter.com/chanezon
-excerpt_separator:
----
-
-### Moby Summit at Docker headquarter
-
-
-
-On June 19 2017, 90 members of the Moby community gathered at Docker headquarter in San Francisco for the second Moby Summit. This was an opportunity for the community to discuss the progress and future of the Moby project, two months after it was announced.
-
-We started the day with an introduction by Solomon Hykes, and a look at the website redesign: the [Moby project website](http://mobyproject.org/) now has a [blog](http://mobyproject.org/blog/), an event calendar, a list of projects, and a [community page](http://mobyproject.org/community/) with links to various community resources. The [website code is open source](https://github.com/moby/mobywebsite), issues and PRs to write guest blog posts or enhance it are welcome.
-
-Then each team gave an update on their progress: Linuxkit, containerd, InfraKit, SwarmKit and LibNetwork, as well as the three new [Moby Special Interest Groups](http://mobyproject.org/projects/), Linuxkit Security, Security Scanning & Notary and Orchestration Security. All these talks have been recorded and you can find the videos and slides below.
-
-In the afternoon, we split into 5 Birds Of Feathers (BOF) sessions: runc/containerd, LinuxKit, InfraKit, Security, and Security Scanning. You can find links to the BOF Notes at the end of this post.
-
-We ended the day with a recap of the BOF sessions, and some beer.
-
-### Moby Summit Introduction
-
-
-
-Slides: [Moby Summit Introduction](https://www.slideshare.net/chanezon/moby-introduction-june-2017)
-
-### LinuxKit Update
-
-
-
-Slides: [LinuxKit update](https://www.slideshare.net/Docker/linuxkit-update-at-the-moby-summit)
-
-### containerd Update
-
-
-
-### InfraKit Update
-
-
-
-Slides: [Infrakit update](http://www.slideshare.net/Docker/infrakit-update-at-moby-summit-june-2017)
-
-### SwarmKit update
-
-
-
-[Swarm Proxy](https://github.com/dperny/swarm-proxy) is a program for managing Docker Swarm services behind a reverse proxy. It uses the Docker events stream to monitor for services being created and removed, and then uses Swarm Configs to update a reverse proxy service to correctly route traffic to those services. It is stateless.
-
-### Libnetwork update
-
-
-
-Slides: [Libnetwork update](http://www.slideshare.net/Docker/libnetwork-update-at-moby-summit-june-2017)
-
-### Security Update
-
-Finally, the Docker security team gave the update on the following topics:
-* LinuxKit security update
-* Security scanning and Notary update
-* Orchestration security update
-
-
-
-Slides: [LinuxKit Security and container container scanning with Notary](https://www.slideshare.net/Docker/llinuxkit-security-security-scanning-and-notary)
-
-Slides: [Orchestration security](https://www.slideshare.net/diogomonica/moby-sig-orchestration-security-summit-presentation)
-
-### BOF Summary Notes
-* [runC / containerd](https://github.com/containerd/containerd/blob/master/reports/2017-06-23.md)
-* [LinuxKit](https://github.com/linuxkit/linuxkit/blob/master/reports/2017-06-19-summit.md)
-* [Security Scanning & Notary](https://forums.mobyproject.org/t/2017-06-19-meeing-notes/79)
-* [Orchestration Security](https://forums.mobyproject.org/t/2017-06-19-orchestration-security-sig-meeting/90)
-
-[Tweet "Check out the videos & slides from the last @moby Summit #containerd #linuxkit #infrakit "](https://twitter.com/share?text=+Check+out+videos+and+slides+from+the+last+Moby+Summit+%23containerd+%23linuxkit+%23infrakit+&via=moby&related=moby&url=https://mobyproject.org/blog/2017/06/26/moby-summit-recap/)
-
-
diff --git a/src/blog/_posts/2017-06-26-sign-all-the-things.md b/src/blog/_posts/2017-06-26-sign-all-the-things.md
deleted file mode 100644
index 039f72c..0000000
--- a/src/blog/_posts/2017-06-26-sign-all-the-things.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Sign all the things!
-layout: post
-author: Riyaz Faizullabhoy
-author-url: https://twitter.com/riyazdf
-excerpt_separator:
----
-
-## Notary + LinuxKit deep dive
-
-Just a few months ago, we open sourced [LinuxKit](https://github.com/linuxkit/linuxkit), a toolkit to build secure, lean, and portable Linux subsystems. One of the key features of LinuxKit lies in its componentization: each of its individual components, including its kernel and system services, are completely swappable.
-
-As you can imagine, it is important to _trust_ each and every one of these components so you can be sure your LinuxKit subsystem is assembled securely. In particular, you should be able to understand _where_ the components come from, _what_ they are supposed to include, and _when_ you should stop using them in case they become out of date. This is a hard requirement for every package – after all, a system is only as secure as its most vulnerable component.
-
-With this goal in mind, the LinuxKit team has been using [Notary](https://github.com/docker/notary), a signing and verification framework that is also part of the Moby Project, to make this easy. Today, every LinuxKit package is signed with Notary. We’d like to tell you more about what this means for your LinuxKit subsystems today, and what you can expect in the future.
-
-
-## Why Notary?
-
-Cryptographic signing is an absolute necessity for establishing trust over content sent over an untrusted media such as the internet. While there are many cryptographic signing systems available for use, most only provide integrity and authenticity guarantees - that the package contents were not modified, and that it was signed off by a key you trust.
-
-Notary not only provides integrity and authenticity, but goes above and beyond by providing _survivable key compromise_ and _freshness_ properties.
-
-By providing survivable key compromise, Notary ensures that any key can be seamlessly rotated out without breaking any trust or functionality in the system. This is particularly important if part of your signing process occurs in online, more exposed environments, where keys are more likely to be exfiltrated. Additionally, it’s difficult in many other signing frameworks to rotate the keys without discarding the root of trust or manually configuring subkeys.
-
-Freshness ensures that you cannot download an old package, or get frozen in time on a stale package. This is a common issue in many signing systems: because it is difficult to invalidate or expire signatures, old and potentially vulnerable packages often carry still-valid signatures (ex: openssl with Heartbleed).
-
-Notary achieves these guarantees by signing separate metadata to capture context about its packages. It’s worth mentioning that Notary and the signed metadata it produces is an implementation of [The Update Framework](https://theupdateframework.github.io/), which is a research project based from [NYU](https://www.nyu.edu/) that has been published and discussed in several peer-reviewed academic publications.
-
-
-## Notary + LinuxKit: better together
-
-### Perfect for our packaging
-
-LinuxKit uses Docker images as the distribution format for all of its packages, including its kernel and init process, and the Docker Hub to store them. While Notary can sign over any type of content, Docker includes a robust and easy-to-use integration known as [Docker Content Trust](https://blog.docker.com/2015/08/content-trust-docker-1-8/). By simply exporting `DOCKER_CONTENT_TRUST=1`, Docker will verify all signatures on pull, and sign images on push.
-
-
-
-We also implemented a trust validation step in the `moby` build tool by leveraging the Notary library. Any packages that are specified by image or organization name in the LinuxKit yaml file will be verified using the Notary library. Today, all LinuxKit packages in the `linuxkit` organization in Docker Hub are signed:
-
-
-
-### Collaboration made easy
-
-Each LinuxKit maintainer has their own key for signing purposes. These keys map to less-privileged roles in Notary known as delegations - not only does this prevent the need for sharing any private key material, but it also works seamlessly with Docker Content Trust, such that `DOCKER_CONTENT_TRUST=1 docker push linuxkit/kernel:4.9.x` pushes and signs with the appropriate keys. That said, the LinuxKit team went an extra step further to ensure that every Makefile for LinuxKit packages includes Docker Content Trust on every pull and push, so running `make` also works for convenience.
-
-
-
-As we can see above, each maintainer has their own key and role, and there are a couple of extra roles for release management and CI. We can easily determine which role and key signed off on a package because that context is captured in Notary’s metadata, for example [Rolf](https://github.com/rn) has signed off on several of the 4.10 series kernel packages:
-
-
-
-Using Notary delegations, we can not only audit who signed the packages, but enforce policy about the signatures on a package. For example: a package could require a simple threshold of two signatures, or even signoff from two maintainers and CI to be considered valid.
-
-## A trusted package manager
-
-Today, Notary and Docker Content Trust are deeply integrated into all LinuxKit packages, not only providing strong cryptographic and usability features, but ultimately equipping LinuxKit with a trusted package manager.
-
-A great example of this integration is how the `moby` tool leverages Notary during offline builds for a LinuxKit image. If the `moby` tool detects it is offline when trying to update to the latest signed data for an individual package, it will fall back to already trusted data from a previous validation if the data is still unexpired. It will perform the same signature verification step using the key data it had previously trusted, and output a warning to the prompt to inform the user that there may be a more up to date version remotely for when they can get back online:
-
-
-
-Overall, the LinuxKit team is excited to leverage Notary’s state-of-the-art signing and verification features, and we view it as a fundamental step to establish trust in our packages - to us, if a LinuxKit package isn’t signed by Notary, it should be as if _it doesn’t exist_.
-
-Going forward, there are many features of Notary yet to explore: fine-grained auditing, signature threshold policy enforcement, and even key pinning to our roots of trust. We look forward to more advanced integrations between Notary and LinuxKit.
diff --git a/src/blog/_posts/2017-08-15-containerd-getting-started.md b/src/blog/_posts/2017-08-15-containerd-getting-started.md
deleted file mode 100644
index ed91790..0000000
--- a/src/blog/_posts/2017-08-15-containerd-getting-started.md
+++ /dev/null
@@ -1,342 +0,0 @@
----
-title: Getting Started with containerd
-layout: post
-author: Michael Crosby
-author-url: https://github.com/crosbymichael
-excerpt_separator:
----
-
-# Getting started with containerd
-
-There are many different ways to use containerd.
-If you are a developer working on containerd you can use the `ctr` tool to quickly test features and functionality without writing extra code.
-However, if you want to integrate containerd into your project we have an easy to use client package that allows you to work with containerd.
-
-In this guide we will pull and run a redis server with containerd using the client package.
-We will assume that you are running a modern linux host for this example with a compatible build of `runc`.
-
-## Starting containerd
-
-You can download one of the latest builds for containerd on the [github releases](https://github.com/containerd/containerd/releases) page and then use your favorite process supervisor to get the daemon started.
-If you are using systemd, we have a `containerd.service` file at the root of the repository that you can use.
-
-The daemon also uses a configuration file located in `/etc/containerd/config.toml` for specifying daemon level options.
-A sample configuration file looks like this:
-
-```toml
-subreaper = true
-oom_score = -999
-
-[debug]
- level = "debug"
-
-[metrics]
- address = "127.0.0.1:1338"
-
-[plugins.linux]
- runtime = "runc"
- shim_debug = true
-```
-
-The default configuration can be generated via `containerd config default > /etc/containerd/config.toml`.
-
-## Connecting to containerd
-
-We will start a new `main.go` file and import the containerd root package that contains the client.
-
-
-```go
-package main
-
-import (
- "log"
-
- "github.com/containerd/containerd"
-)
-
-func main() {
- if err := redisExample(); err != nil {
- log.Fatal(err)
- }
-}
-
-func redisExample() error {
- client, err := containerd.New("/run/containerd/containerd.sock")
- if err != nil {
- return err
- }
- defer client.Close()
- return nil
-}
-```
-
-This will create a new client with the default containerd socket path.
-Because we are working with a daemon over GRPC we need to create a `context` for use with calls to client methods.
-containerd is also namespaced for callers of the API.
-We should also set a namespace for our guide after creating the context.
-
-```go
- ctx := namespaces.WithNamespace(context.Background(), "example")
-```
-
-Having a namespace for our usage ensures that containers, images, and other resources without containerd do not conflict with other users of a single daemon.
-
-## Pulling the redis image
-
-Now that we have a client to work with we need to pull an image.
-We can use the redis image based on alpine linux from the DockerHub.
-
-```go
- image, err := client.Pull(ctx, "docker.io/library/redis:alpine", containerd.WithPullUnpack)
- if err != nil {
- return err
- }
-```
-
-The containerd client uses the `Opts` pattern for many of the method calls.
-We use the `containerd.WithPullUnpack` so that we not only fetch and download the content into containerd's content store but also unpack it into a snapshotter for use as a root filesystem.
-
-## Creating an OCI Spec and Container
-
-Now that we have an image to base our container off of, we need to generate an OCI runtime specification that the container can be based off of.
-
-containerd provides reasonable defaults for generating OCI runtime specs.
-There is also an `Opt` for modifying the default config based on the image that we pulled.
-
-```go
- spec, err := containerd.GenerateSpec(containerd.WithImageConfig(ctx, image))
- if err != nil {
- return err
- }
-```
-
-After we have a spec generated we need to create a container.
-The container will be based off of the image, use the runtime information in the spec that was just created, and we will allocate a new read-write snapshot so the container can store any persistent information.
-
-```go
- container, err := client.NewContainer(
- ctx,
- "redis-server",
- containerd.WithSpec(spec),
- containerd.WithImage(image),
- containerd.WithNewSnapshot("redis-server-snapshot", image),
- )
- if err != nil {
- return err
- }
- defer container.Delete(ctx, containerd.WithSnapshotCleanup)
-```
-
-When creating a new snapshot for the container we need to provide a snapshot ID as well as the Image that the container will be based on.
-By providing a separate snapshot ID than the container ID we can easily reuse, existing snapshots across different containers.
-
-We also add a line to delete the container along with its snapshot after we are done with this example.
-
-## Creating a running Task
-
-One thing that may be confusing at first for new containerd users is the separation between a `Container` and a `Task`.
-A container is a metadata object that resources are allocated and attached to.
-A task is a live, running process on the system.
-Tasks should be deleted after each run while a container can be used, updated, and queried multiple times.
-
-```go
- task, err := container.NewTask(ctx, containerd.Stdio)
- if err != nil {
- return err
- }
- defer task.Delete(ctx)
-```
-
-The new task that we just created is actually a running process on your system.
-We use the `containerd.Stdio` `Opt` so that all IO from the container is sent to our `main.go` process.
-
-If you are familiar with the OCI runtime actions, the task is currently in the "created" state.
-This means that the namespaces, root filesystem, and various container level settings have been initialized but the user defined process, in this example "redis-server", has not been started.
-This gives users a chance to setup network interfaces or attach different tools to monitor the container.
-containerd also takes this opportunity to monitor your container as well.
-Waiting on things like the container's exit status and cgroup metrics are setup at this point.
-
-If you are familiar with prometheus you can curl the containerd metrics endpoint (in the `config.toml` that we created) to see your container's metrics:
-
-```bash
-> curl 127.0.0.1:1228/metrics
-```
-
-Pretty cool right?
-
-## Task Wait and Start
-
-Now that we have a task in the created state we need to make sure we that we wait on the task to exit so that we can close our example and cleanup the resources that we created.
-You always want to make sure you `Wait` before calling `Start` on a task.
-This makes sure that you do not encounter any races if the task has a simple program like `/bin/true` that exits promptly after calling start.
-
-```go
- exitStatusC := make(chan uint32, 1)
- go func() {
- status, err := task.Wait(ctx)
- if err != nil {
- fmt.Println(err)
- }
- exitStatusC <- status
- }()
-
- if err := task.Start(ctx); err != nil {
- return err
- }
-```
-
-Now we should see the `redis-server` logs in our terminal when we run the `main.go` file.
-
-## Killing the task
-
-Since we are running a long running server we will need to kill the task in order to exit out of our example.
-To do this we will simply call `Kill` on the task after waiting a couple of seconds so we have a chance to see the redis-server logs.
-
-```go
- time.Sleep(3 * time.Second)
-
- if err := task.Kill(ctx, syscall.SIGTERM); err != nil {
- return err
- }
-
- status := <-exitStatusC
- fmt.Printf("redis-server exited with status: %d\n", status)
-```
-
-We wait on our exit status channel that we setup to ensure the task has fully exited and we get the exit status.
-If you have to reload containers or miss waiting on a task, `Delete` will also return the exit status when you finally delete the task.
-We got you covered.
-
-```go
-status, err := task.Delete(ctx)
-```
-
-## Full Example
-
-Here is the full example that we just put together.
-
-```go
-package main
-
-import (
- "context"
- "fmt"
- "log"
- "syscall"
- "time"
-
- "github.com/containerd/containerd"
- "github.com/containerd/containerd/namespaces"
-)
-
-func main() {
- if err := redisExample(); err != nil {
- log.Fatal(err)
- }
-}
-
-func redisExample() error {
- // create a new client connected to the default socket path for containerd
- client, err := containerd.New("/run/containerd/containerd.sock")
- if err != nil {
- return err
- }
- defer client.Close()
-
- // create a new context with an "example" namespace
- ctx := namespaces.WithNamespace(context.Background(), "example")
-
- // pull the redis image from DockerHub
- image, err := client.Pull(ctx, "docker.io/library/redis:alpine", containerd.WithPullUnpack)
- if err != nil {
- return err
- }
-
- // generate an OCI runtime spec using the Args, Env, etc from the redis image that we pulled
- spec, err := containerd.GenerateSpec(containerd.WithImageConfig(ctx, image))
- if err != nil {
- return err
- }
-
- // create a container
- container, err := client.NewContainer(
- ctx,
- "redis-server",
- containerd.WithSpec(spec),
- containerd.WithImage(image),
- containerd.WithNewSnapshot("redis-server-snapshot", image),
- )
- if err != nil {
- return err
- }
- defer container.Delete(ctx, containerd.WithSnapshotCleanup)
-
- // create a task from the container
- task, err := container.NewTask(ctx, containerd.Stdio)
- if err != nil {
- return err
- }
- defer task.Delete(ctx)
-
- // make sure we wait before calling start
- exitStatusC := make(chan uint32, 1)
- go func() {
- status, err := task.Wait(ctx)
- if err != nil {
- fmt.Println(err)
- }
- exitStatusC <- status
- }()
-
- // call start on the task to execute the redis server
- if err := task.Start(ctx); err != nil {
- return err
- }
-
- // sleep for a lil bit to see the logs
- time.Sleep(3 * time.Second)
-
- // kill the process and get the exit status
- if err := task.Kill(ctx, syscall.SIGTERM); err != nil {
- return err
- }
-
- // wait for the process to fully exit and print out the exit status
-
- status := <-exitStatusC
- fmt.Printf("redis-server exited with status: %d\n", status)
-
- return nil
-}
-```
-
-We can build this example and run it as follows to see our hard work come together.
-
-```bash
-> go build -o example main.go
-> sudo ./example
-
-1:C 04 Aug 20:41:37.682 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
-1:C 04 Aug 20:41:37.682 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=1, just started
-1:C 04 Aug 20:41:37.682 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
-1:M 04 Aug 20:41:37.682 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
-1:M 04 Aug 20:41:37.682 # Server can't set maximum open files to 10032 because of OS error: Operation not permitted.
-1:M 04 Aug 20:41:37.682 # Current maximum open files is 1024. maxclients has been reduced to 992 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
-1:M 04 Aug 20:41:37.683 * Running mode=standalone, port=6379.
-1:M 04 Aug 20:41:37.683 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
-1:M 04 Aug 20:41:37.684 # Server initialized
-1:M 04 Aug 20:41:37.684 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
-1:M 04 Aug 20:41:37.684 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
-1:M 04 Aug 20:41:37.684 * Ready to accept connections
-1:signal-handler (1501879300) Received SIGTERM scheduling shutdown...
-1:M 04 Aug 20:41:40.791 # User requested shutdown...
-1:M 04 Aug 20:41:40.791 * Saving the final RDB snapshot before exiting.
-1:M 04 Aug 20:41:40.794 * DB saved on disk
-1:M 04 Aug 20:41:40.794 # Redis is now ready to exit, bye bye...
-redis-server exited with status: 0
-```
-
-In the end, we really did not write that much code when you use the client package.
-
-I hope this guide helped to get you up and running with containerd.
-Feel free to join the [slack channel](https://dockr.ly/community) if you have any questions and like all things, if you want to help contribute to containerd or this guide, submit a pull request.
diff --git a/src/blog/index.html b/src/blog/index.html
deleted file mode 100644
index 685f297..0000000
--- a/src/blog/index.html
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Moby Blog
-layout: blog
----
-
-{% assign posts_collate = site.posts %}
-{% for post in posts_collate %}
- {% capture this_year %}{{ post.date | date: "%Y" }}{% endcapture %}
- {% capture this_month %}{{ post.date | date: "%B" }}{% endcapture %}
- {% capture next_year %}{{ post.previous.date | date: "%Y" }}{% endcapture %}
- {% capture next_month %}{{ post.previous.date | date: "%B" }}{% endcapture %}
-
- {% if forloop.first %}
- {% comment %}
- {{ content }}
-
-{{this_month}}
{% endcomment %} --
- {% endif %}
-
-
- {{ post.date | date: "%d %b %Y" }} » {{ post.title }}{{ post.excerpt }} - - {% if forloop.last %} -
{{next_year}}
- {% comment %}{{next_month}}
{% endcomment %} --
- {% else %}
- {% if this_month != next_month %}
-
{{next_month}}
{% endcomment %} --
- {% endif %}
- {% endif %}
- {% endif %}
-{% endfor %}
-
-{% assign posts_collate = nil %}
\ No newline at end of file
diff --git a/src/community.md b/src/community.md
index 1c1f2c9..361525c 100644
--- a/src/community.md
+++ b/src/community.md
@@ -3,42 +3,6 @@ title: Moby
layout: community
---
-
- Anyone curious about containers and looking for an easy way to learn. We recommend the docker.com website instead
-
Meet our contributors
-
-{% for contributor in site.data.contributors %}
-
-
-
- ![]()
-
-
-
-
-
-
-
-
-{% endfor %}
-
-
-What is the community saying?
-
- Tweets by moby
-
-
{% include social.html %}
diff --git a/src/index.md b/src/index.md
index 16cc12b..b4d2899 100644
--- a/src/index.md
+++ b/src/index.md
@@ -64,32 +64,6 @@ layout: home
-
-
-
-
-
-
-
- Moby defines the future in specialized container systems building.
- - -- -### Technical Steering Committee - -The Technical Steering Committee acts as an escalation point for conflicts within projects, encourages cross-project communication and coordination, as well as helping with project governance. The TSC is not involved in the day-to-day activities of the projects but can resolve technical disputes when an issue has been escalated to the committee. - -Seats on the committee are allocated by election and seats are held for a fixed term. You can read more about the Technical Steering Committee, including the list of [current members](https://github.com/moby/tsc/blob/master/MEMBERS.md), over on the [TSC repository](https://github.com/moby/tsc). - -
- -### Moby Special Interest Groups - -Moby Project also hosts Special Interest Groups (SIG) for discussing subtopics among interested contributors. SIGs typically meet every week and post their meeting minutes and video of the meetings online. If you're interested in starting a SIG, please begin a discussion on the [forum](https://forums.mobyproject.org). - -**Current SIGs** - -| Name | Leads | Agenda | Forum | Meetings | -|------|-------|--------|-------|----------| -| [LinuxKit Security](https://github.com/linuxkit/linuxkit/tree/master/sigs/security) | [@riyazdf](https://github.com/riyazdf) Riyaz Faizullabhoy | [Agenda and Meeting Notes](https://github.com/linuxkit/linuxkit/tree/master/reports/sig-security) | [Forum](https://forums.mobyproject.org/c/sig/linuxkit-security) | [Every other Wednesday at 9:00 AM PST](https://docker.zoom.us/j/779801882) | -| [Orchestration Security](https://github.com/docker/swarmkit/tree/master/sigs/orchestration-security) | [@diogomonica](https://github.com/diogomonica) Diogo Monica | [Agenda and Meeting Notes](https://docs.google.com/document/d/1co6Jv9Mq8jeToK-sYNNXwUQiPWcDCvlNJ5bozAOfriE/edit) | [Forum](https://forums.mobyproject.org/c/sig/orchestration-security) | [Every other Tuesday at 3:00 PM PST](https://docker.zoom.us/j/417366441) | +The projects themselves provide a "Lego set" of toolkit components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts and professionals to experiment and exchange ideas.