Merge pull request #27 from hlgr360/master
Adding Haufe picture, updating markdown processor
This commit is contained in:
commit
1f7b6a6a6b
|
@ -56,8 +56,8 @@ baseurl: ""
|
|||
# !! You don't need to change any of the configuration flags below !!
|
||||
#
|
||||
|
||||
markdown: redcarpet
|
||||
highlighter: pygments
|
||||
markdown: kramdown
|
||||
highlighter: rouge
|
||||
permalink: /:title/
|
||||
|
||||
# default pagination
|
||||
|
|
|
@ -23,7 +23,8 @@
|
|||
<!-- suppress all category and tag meta pages -->
|
||||
{% if page.url contains '/meta/' %}
|
||||
{% else %}
|
||||
{% if page.url != '/404.html' %}
|
||||
{% if page.url contains '404' %}
|
||||
{% else %}
|
||||
<li>
|
||||
<a href="{{ page.url | prepend: site.baseurl }}">{{ page.title }}</a>
|
||||
</li>
|
||||
|
|
|
@ -8,6 +8,7 @@ author: ThomasSc
|
|||
author_email: thomas.schuering@haufe-lexware.com
|
||||
header-img: "images/bg-post.jpg"
|
||||
---
|
||||
|
||||
Once upon a time in a ~~galaxy~~ container far, far away ... We, a bunch or ~~rebels~~ Haufe-employees, entered the halls of container - wisdom: DockerCon EU 2015 in Barcelona, Spain. Hailing from different departments and locations (Freiburg AND Timisoira, CTO's, ICT, DevOps, ...), the common goal was to learn about the current state of Docker, the technology behind it and its evolving eco-system.
|
||||
|
||||
The unexpected high level catering (at least on the first day and the DockerCon Party in the Marine Museum) was asking for more activity than moving from one session to the next, but we had to bear that burden (poor us!).
|
||||
|
@ -48,10 +49,8 @@ Here's what I found most important (no specific order and might be intermixed wi
|
|||
|
||||
In the meantime have a look at the [great overview](https://github.com/docker-saigon/dockercon-eu-2015) what happened during both days with links to all/most of the presentations, slides or videos to be found a .
|
||||
|
||||
# Things "inbetween"
|
||||
## Things "inbetween"
|
||||
... were quite interesting, too. We met with some guys from Zalando (yes, the guys who're screeming a lot in their adverts), who were explaining how they are using some home-brewn (git-available) facade (or tool if you like) to ease the pain with running a custom PaaS on AWS. The project [STUPS](https://stups.io/) uses a plethora of Docker-containers and is to be found on its own web-page and [github](https://github.com/zalando-stups) .
|
||||
|
||||
(To be extended :-))
|
||||
(To be continued :-))
|
||||
|
||||
#
|
||||
There's more to come (from other colleagues, too :-)
|
||||
|
|
|
@ -15,17 +15,17 @@ First of all, some background, although [Docker](https://www.docker.com/what-doc
|
|||
|
||||
So I was excited to visit DockerCon and see how Docker continued to evolve as platform into a very flexible, lightweight virtualization platform. The Docker universe indeed made big steps under the hood, with the tooling around it, and also with a growing number of third party adopters improving many aspects of what Docker is and wants to be. Docker may and will revolutionize the way we will build and deploy software in the future. And the future starts now, in the projects we bring ahead.
|
||||
|
||||
##Virtualization and Docker##
|
||||
### Virtualization and Docker
|
||||
|
||||
The past waves of virtualization are now commodity, has reached IT and is no longer the domain of development as it was years ago, when we started with VMware for development and testing. It is the base for nowadays deployment. Virtualization has many aspects and flavours, but one thing is in common: it is rather heavy weighted to build up a virtualization platform, and using it will cause some performance reduction in comparision to deploying software artifacts directly to physical machines - what was still done for this reason, to have maximum throughput and optimal performance for business. But with virtualization we gain flexibility, beeing able to move a virtualized computing unit on the hardware below, especially from an older system to a newer one without having to rebuild, repackage or deploy anything. And it is already a big, well known industry behind virtualization infrastructure and technology.
|
||||
|
||||
So what is new with Docker? First of all, Docker is *very lightweight*. It fits well in modern Unix enviroments as it bases upon kernel features like CGroups, LXC and more to provide a separation of the runtime environment for the application components from the base os system and drivers and hardware below. But docker is not linux only, there is movement also in the non-Linux part of our world implementing docker and docker related services. Important is: Docker is not about VMs, it is containers. Docker as technology and platform promises to become a radical shift in view. But as I am no authority in this domain, I just refer to a recent article on why Docker is [the biggest disruption in Linux virtualization](http://www.nextplatform.com/2015/11/06/linux-containers-will-disrupt-virtualization-incumbents/).
|
||||
|
||||
##Docker fundamentals##
|
||||
### Docker fundamentals
|
||||
|
||||
There was one session that made a deep impression on me. It was the session titled ["Cgroups, namespaces and beyond: what are containers made from"](http://de.slideshare.net/Docker/cgroups-namespaces-and-beyond-what-are-containers-made-from) by Jerome Pettazzoni. Jerome shows how Docker bases on and evolves from Linux features like cgroups and namespaces and LXC (Linux containers). Whereas early docker releases based on LXC, it uses now an own abstraction from underlying OS and Linux kernel called libcontainer. He show containers can be built from out of the box linus features in an impressive demo. The main message I took from this presentation: Docker introduces no overhead in comparision to direct deployment to a linux system, as the mechanism used by Docker are system inherent, it means are also used and in effect when one uses Linux without, as they sit there and are used anywhere. Docker is lightweight, really, and has nearly no runtime overhead, so it should be the natural way to deploy and use non-OS software components on Linux.
|
||||
|
||||
##Docker and Security##
|
||||
### Docker and Security
|
||||
|
||||
When I started in 2014, one message from IT was: Docker is insecure, and not ready for production use, we cannot support it. Indeed there are a couple of security issues related to Docker, especially if the application to deploy depends on NFS needed to share configuration data and provide a central pool of storage to be accessed by a multi-node system (as HRS is, for reasons of scaling and load balancing). In a Docker container, you are root, and this implies also root access to underlying services, such as NFS mounted volumes. Nowadays, still true, unfortunately. You will find the discussions in various discussion groups in the internet. For example in ["NFS Security in Docker"](https://groups.google.com/forum/#!topic/docker-user/baFYhFZp0Uw) and many more.
|
||||
|
||||
|
@ -36,20 +36,20 @@ An other progress with container security is the project [Notary and docker cont
|
|||
More technical information on it can be read in the blog article [Docker Content Trust](https://blog.docker.com/2015/08/content-trust-docker-1-8/).
|
||||
See also the [InnoQ article](http://www.infoq.com/news/2015/11/docker-security-containers) and the [presentation](https://blog.docker.com/2015/05/understanding-docker-security-and-best-practices/) from May 2015.
|
||||
|
||||
##Stateless vs Persistency##
|
||||
### Stateless vs Persistency
|
||||
|
||||
One thing that struck me last year, when I worked on my Docker prototype implementation, was that Docker is perfect for stateless services. But troubles are ahead, as in real world projects, many services tend to be stateful, with more or less heavy dependencies on configuration and data. This has to be handled with care when constructing Docker containers - and I indeed ran into a problems with that in my experiments.
|
||||
|
||||
I hoped to hear more on this topic, as I guess I am probably not the only one that has run into issues while constructing docker containers.
|
||||
Advances in docker volumes where mentioned, indeed. Here I mention the session "Persistent, stateful services with docker clusters, namespaces and docker volume magic" by Michael Neale.
|
||||
|
||||
##Usecase and Messages##
|
||||
### Usecase and Messages
|
||||
As a contrast to the large number of rather technology focussed sessions was the one held by Ian Miell - author of 'Docker in Practice' - on ["Cultural Revolution - How to Manage the Change Docker brings"](http://de.slideshare.net/Docker/cultural-revolution-how-to-mange-the-change-docker-brings)
|
||||
|
||||
A use case presentation was "Continuous Integration with Jenkins, Docker and Compose", held by Sandro Cirulli, Platform Tech Lead of Oxford University Press (OUP). He presents the devops workflow used with OUP for building and deploying two websites provising resources for digitally under represented languages. The infrastructure runs on Docker containers, with Jenkins used to rebuild the Docker Images for the API based on a Python Flask application and Docker Compose to orchestrate the container. The CI workflow and demo of how continuous integration was achived were given in the presentation. It is available in [slideshare](http://de.slideshare.net/Docker/continuous-integration-with-jenkins-docker-and-compose), too.
|
||||
|
||||
One big message hovered over the whole conference: Docker is evolving ... as an open source project that is not only based on a core team but also heavily on many constributors making it grow and become a success story. Here to mention the presentation ["The Missing Piece: when Docker networking unleashing soft architecture 2.0"](http://de.slideshare.net/Docker/the-missing-piece-when-docker-networking-unleashing-soft-architecture-v15). And "Intro to the Docker Project: Engine, Networking, Swarm, Distribution" that rouse some expectations that were not met by the speaker, unfortunately.
|
||||
|
||||
##Session Overview##
|
||||
### Session Overview
|
||||
An overview on the sessions held at DockerCon 2015 in Barcelona can be found [here](https://github.com/ngtuna/dockercon-eu-2015/blob/master/README.md), together with many links to the announcements made, presentations for most sessions in slideshare, and links to youtube videos of the general sessions, of which I recommented viewing the one for [day 2 closing general session](https://www.youtube.com/watch?v=ZBcMy-_xuYk) with a couple of demonstrations what can be done using Docker. It is entertaining and amazing.
|
||||
|
||||
|
|
|
@ -9,8 +9,6 @@ author_email: doru.mihai@haufe-lexware.com
|
|||
header-img: "images/bg-post.jpg"
|
||||
---
|
||||
|
||||
# Approaches to log parsing
|
||||
|
||||
When you will start to deploy your log shippers to more and more systems you will encounter the issue of adapting your solution to be able to parse whatever log format and source each system is using. Luckily, fluentd has a lot of plugins and you can approach a problem of parsing a log file in different ways.
|
||||
|
||||
|
||||
|
@ -51,7 +49,7 @@ If more pieces are common to all messages, it can be included in the regex for s
|
|||
As the name would suggest, this approach suggests that you should try to create an internal routing that would allow you to precisely target log messages based on their content later on downstream.
|
||||
An example of this is shown in the configuration below:
|
||||
|
||||
~~~ruby
|
||||
~~~
|
||||
#Sample input:
|
||||
#2015-10-15 08:19:05,190 [testThread] INFO testClass - Queue: update.testEntity; method: updateTestEntity; Object: testEntity; Key: 154696614; MessageID: ID:test1-37782-1444827636952-1:1:2:25:1; CorrelationID: f583ed1c-5352-4916-8252-47298732516e; started processing
|
||||
#2015-10-15 06:44:01,727 [ ajp-apr-127.0.0.1-8009-exec-2] LogInterceptor INFO user-agent: check_http/v2.1.1 (monitoring-plugins 2.1.1)
|
||||
|
@ -114,7 +112,7 @@ You can use *fluent-plugin-multi-format-parser* to try to match each line read f
|
|||
This approach probably comes with performance drawbacks because fluentd will try to match using each regex pattern sequentially until one matches.
|
||||
An example of this approach can be seen below:
|
||||
|
||||
~~~ruby
|
||||
~~~
|
||||
<source>
|
||||
type tail
|
||||
path /var/log/aka/test.log
|
||||
|
@ -171,21 +169,19 @@ When choosing this path there are multiple issues you need to be aware of:
|
|||
|
||||
The biggest issue with this approach is that it is very very hard to handle multi-line log messages if there are significantly different log syntaxes in the log.
|
||||
|
||||
|
||||
__Warning:__ Be aware that the multiline parser continues to store log messages in a buffer until it matches another firstline token and when it does it then it packages and emits the multiline log it collected.
|
||||
This approach is useful when you have good control and know-how about the format of your log source.
|
||||
|
||||
## Order & Chaos
|
||||
Introducing Grok!
|
||||
|
||||
|
||||
Slowly but surely getting all your different syntaxes, for which you will have to define different regular expressions, will make your config file look very messy, filled with regex-es that are longer and longer, and just relying on the multiple format lines to split it up doesn't bring that much readability nor does it help with maintainability. Reusability is something that we cannot even discuss in the case of pure regex formatters.
|
||||
|
||||
|
||||
Grok allows you to define a library of regexes that can be reused and referenced via identifiers. It is structured as a list of key-value pairs and can also contain named capture groups.
|
||||
An example of such a library can be seen below. (Note this is just a snippet and does not contain all the minor expressions that are referenced from within the ones enumerated below)
|
||||
|
||||
~~~ruby
|
||||
~~~
|
||||
###
|
||||
# AKA-I
|
||||
###
|
||||
|
|
4
about.md
4
about.md
|
@ -12,11 +12,11 @@ The Haufe Group stands for integrated cloud and desktop solutions in the areas o
|
|||
|
||||
The main target groups are large and midsize firms, small businesses and freelancers, tax advisers and lawyers, the public sector, real estate agents, and nonprofit organizations. A number of our brands – Haufe, Haufe Academy, and Lexware – are market leaders in these target groups.
|
||||
|
||||
####Corporate background
|
||||
#### Corporate Background
|
||||
|
||||
The Haufe Group emerged from a successful publisher and the provider of Lexware, a leading source of commercial software for small firms; over time, it grew to offer a comprehensive portfolio of digital and web-based solutions. Its wide range of products and services have been merged in integrated workstation solutions that allow customers to work effectively.
|
||||
|
||||
####Current market Position
|
||||
#### Current Market Position
|
||||
|
||||
The Haufe Group is now considered one of the most innovative media and software vendors in Germany. Its solutions use state-of-the-art technology and are very user-friendly and practice-oriented. More than one million customers – including all DAX 30 firms – generate over 266 million euros in revenue. The Freiburg-based firm currently has some 1,500 employees within Germany and abroad. The Group's international growth strategy is based on its current product portfolio, and it expands on an ongoing basis thanks to the synergies which evolve from the core competencies and strengths of the individual firms and brands within the Group.
|
||||
|
||||
|
|
|
@ -144,8 +144,11 @@ hr.small {
|
|||
margin-bottom: 50px;
|
||||
}
|
||||
.intro-header .site-heading,
|
||||
.intro-header .post-heading,
|
||||
.intro-header .page-heading {
|
||||
padding: 100px 0 50px;
|
||||
color: black;
|
||||
}
|
||||
.intro-header .post-heading {
|
||||
padding: 100px 0 50px;
|
||||
color: white;
|
||||
}
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 169 KiB After Width: | Height: | Size: 181 KiB |
Binary file not shown.
Before Width: | Height: | Size: 66 KiB After Width: | Height: | Size: 45 KiB |
BIN
images/bg-post.old.jpg
Normal file
BIN
images/bg-post.old.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 169 KiB |
|
@ -4,7 +4,6 @@ title: Resources
|
|||
permalink: /resources/
|
||||
---
|
||||
|
||||
---
|
||||
### API Style Guide
|
||||
A List of rules, best practices, resources and our way of creating REST APIs in the Haufe Group. The style guide addresses API Designers, mostly developers and architects, who want to design an API.
|
||||
|
||||
|
|
Loading…
Reference in a new issue