Group items tagged

"The new Docker Registry 2.0 was released on April 16th, 2015. It was completely rewritten in Go with added support for the new Docker Registry HTTP API V2 (thus only working with Docker 1.6+), promising to provide faster and more secure distribution of images. If you work with Docker and for some reason decided not to use the public Docker Hub, a private Docker Registry is an essential part of your architecture. But even if you don't have private images, you will likely need to use your own registry in production/testing for efficiency. The default installation, however, runs without encryption and authentication. I was wondering what's involved in securing it. There is an official tutorial on how to configure TLS on a registry server. TLS/SSL is absolutely necessary for any secure setup, but I also wanted to enable an authentication mechanism. The Configuration Reference document describes two authentication options supported by Docker Registry itself: so-called silly and token solutions. The silly one is apparently only useful for very limited development use-cases. The token solution seems to be more serious, but because of the lack of documentation (at the time of writing), I decided to find an alternative approach to secure it. In this article I'm going to show you how to set up the Docker Registry 2.0 with username/password authentication and SSL using the official Docker Registry image and a custom configured nginx as a proxy server."

"Join Elastic developer Nicholas Knize to get an introduction to Elasticsearch's geospatial capabilities. He will give you a whirlwind tour of how to use Elasticsearch to make the most of your geo data and do things like: Indexing considerations for optimizing geo-point and geo-shape based search Geo-aggregations and bucket reducers for spatial visualization and analytics Time-based indexing, aliasing, and percolation for complex space-time querying But how does Elasticsearch compare to traditional solutions for geospatial search? John Boere, CEO of Cliffhanger Solutions Inc., will share his geospatial search story, giving you insight into their setup, lessons learned, and why they chose to use Elasticsearch, Logstash, and Kibana to help utility companies manage electricity flowing through the power grid - keeping the lights on, literally."

"A typical Java EE application consists of an application server, such as WildFly, and a database, such as MySQL. In addition, you might have a separate front-end tier, say Apache, for load balancing a number of application server. A caching layer, such as Infinispan, may be used to improve overall application performance. Messaging system, such as ActiveMQ, may be used for processing queues. Both the caching and messaging components could be setup as a cluster for further scalability. This Tech Tip will show some simple Docker recipes to configure your containers that use application server and database. Subsequent blog will cover more advanced recipes that will include front-end, caching, messaging, and clustering. "

"Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should

Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.