Planet Friends of Vienna.rb

IoT Vienna - The Internet of Things Group of Vienna

Diese IoT Talks/DigiTalks sind eine Kooperationsveranstaltung von der Digital Society und IoT Vienna:

Internet of Things (IoT) und Cyber Physical Systems (CPS)

Was ist das Internet of Things und warum ist es in aller Munde. Welchen Nutzen bringt IoT für die Menschen ( medizinische Anwendungen & Pflege, Digital Living) sowie für Industrie & Landwirtschaft (Smart Grid, Industrie 4.0, Smart Farming, Logistik)

IoT & Security

IoT bringt enormen Nutzen für unsere Gesellschaft, allerdingst gibt es auch ebenso große Gefahren. Die Devices, die das Internet of Things bilden, können entweder Angriffsziel sein (z.B. Smartmeter um den Strom abzuschalten), oder mittels diesen Devices können auch Angriffe auf andere Ziele gemacht werden wie im Oktober 2015, als davon das Internet fast lahm gelegt wurde.

IoT & Normen

IoT kann und wird sich aber nur vollständig durchsetzen können, wenn die Geräte auch untereinander möglichst ungehindert kommunizieren und zusammenarbeiten können. Dazu sind Normen und Standards notwendig. Welche Normen gibt es? Welche sind in Entstehung (Drafts, z.B. RA – Reference Architecture)

Über die Vortragenden

Ralf Schlatterbeck (* 1964) ist Open Source Experte und Auditor für Sicherheit, er gibt regelmässig Vorträge bei den Linuxwochen oder der DeepSec Konferenz. Seine Schwerpunkte sind IP-Telefonie, sichere Chat-Protokolle und Betriebssicherheit. Er lehrt am FH Technikum in Wien. Homepage http://ww.runtux.com...

Manfred Wöhrl Gerichtlich beeideter und zertifizierter Sachverständiger; seit mehr als 30 Jahren im Bereich der IT mit den Spezialgebieten Innovative Technologien (derzeitiger Schwerpunkt Digital Signage) und IT-Security tätig; war Gründer und Leiter der staatlichen Versuchsanstalt für Datenverarbeitung an der HTL-Spengergasse,  Lehrbeauftragter an der Fachhochschule Krems, sowie Lektor an der Universität Wien, der Donauuniversität und der Wirtschaftsuniversität Wien.

Foto und Video

Wissen und Informationen gehören uns allen. In den meisten Fällen zeichnen wir die IoT Talks auf, um sie auch jenen zur Verfügung stellen können, die nicht dabei sein können. Wir erlauben daher auch Teilnehmern, dass Videos und Fotos gemacht werden. Allerdings müssen diese Werke dann unter die Creative Commons Nutzungslizenz CC0 oder CC-BY gestellt werden. Durch die Teilnahme an der Veranstaltung erklären sich die Teilnehmer einverstanden, dass von ihnen Foto und Videoaufnahmen gemacht werden.

Ablauf

Einlass: 18:00
Vortragsbeginn: 18:30

Zielgruppe: Bürger der digitalen Welt

Dauer des Vortrages: ca. 45 Minuten mit anschließender Diskussion

Danach Networking und Austausch bei Getränken mit den anwesenden Gästen.

Die Veranstaltung ist kostenlos.

Buchung

Anmeldungen bitte über die Webseite der Digital Society: https://digisociety.a...

Vienna - Austria

Wednesday, February 15 at 6:00 PM

2

https://www.meetup.com/IoT-Vienna/events/237169297/

vienna.js Vienna JavaScript User Group

This time we have a special joint event with the amazing people from Angular Vienna. Expect a kick-ass event! Can't wait to meet you there!

Talks:

view-source: https://twitter.com...
Giuseppe Gurgone
An overview of twitter.com's front-end architecture.

Raquel Vèlez
So you want to write some software. And you decide to use npm, because everyone's saying it's the coolest thing ever. Great! But... where do you start? And once you've started, how do you take advantage of the advanced features? Let's write an app together! Whether you're brand new to using npm or have been using it for years, I guarantee you'll learn a new trick or two - or at least get a good laugh!

Sponsors:

We are currently looking for sponsors to cover free beer and maybe free pizza. Contact us at fp@codeq.at

Heia – www.heia-easy.com
Heia's mission is to provide the most attractive web-booking and app solutions for hotels and student homes, embedding the latest technologies and innovations to create a unique customer experience and user handling. 

Being a joint venture between the companies Ameya and CCT Software Solutions, HEIA embodies vast experience in the hospitality industry combined with exclusive access to more than 1.500 hotels, among them many well-known luxury brands.

www.foryouandyourcustomers.com
For our foryouandyourcustomers location in Vienna we are looking for an experienced web developer (f/m), who, in addition to a pragmatic solution-oriented approach, also appreciates a sophisticated software architecture as the basis for efficient and clean implementation.

Kivu Technologies provides clients in the security sector with a ground-breaking automated process to collect, process and analyse vast tracts of data at blazing speeds, while protecting privacy.

Established in 2016, Kivu is forging a new future for big data, disrupting the existing data management platforms and providing with clients with vital, intelligent and reliable real-time analysis. Kivu provides the answers to clients’ key questions, saving the analysts precious time and resources.

http://www.kivu.tech...

Tapkey -www.tapkey.com

Tapkey is dedicated to the creation and proliferation of secure mobile access in a digitally connected world. The company's patented Tapkey solution transforms smartphones into smart keys, making it easy for end users to take advantage of this liberating technology. And with its open platform, the company also makes it easy for channel partners to add Tapkey functionality to their products: Tapkey partners with lock-hardware manufacturers in diverse spaces, helping them build a broad portfolio of Tapkey-empowered solutions. For more information, visit www.tapkey.com.

Vienna - Austria

Wednesday, January 25 at 7:00 PM

163

https://www.meetup.com/viennajs/events/235900594/

Django Friends – Vienna

Our Django meetup in June! Don’t miss it:

14th of June (Wednesday), 19:00 
Sektor 5 - http://www.sektor5.at... – The cosiest coworking space there is! 
Siebenbrunnengasse 44, 1050 Vienna

Looking forward to seeing you at the Meetup, 

Florian & Stephan & Anton 

Vienna - Austria

Wednesday, June 14 at 7:00 PM

2

https://www.meetup.com/Django-Vienna/events/237170275/

Django Friends – Vienna

Our Django meetup in June! Don’t miss it:

7th of November (Tuesday), 19:00 
Sektor 5 - http://www.sektor5.at... – The cosiest coworking space there is! 
Siebenbrunnengasse 44, 1050 Vienna

Looking forward to seeing you at the Meetup, 

Stephan & Anton & Florian 

Vienna - Austria

Tuesday, November 7 at 7:00 PM

1

https://www.meetup.com/Django-Vienna/events/237170340/

Django Friends – Vienna

Our Django meetup in June! Don’t miss it:

5th of September (Tuesday), 19:00 
Sektor 5 - http://www.sektor5.at... – The cosiest coworking space there is! 
Siebenbrunnengasse 44, 1050 Vienna

Looking forward to seeing you at the Meetup, 

Anton & Florian & Stephan 

Vienna - Austria

Tuesday, September 5 at 7:00 PM

3

https://www.meetup.com/Django-Vienna/events/237170300/

Django Friends – Vienna

Our Django meetup in February! Don’t miss it:

14th of February (Tuesday), 19:00 
Sektor 5 - http://www.sektor5.at... – The cosiest coworking space there is! 
Siebenbrunnengasse 44, 1050 Vienna

Looking forward to seeing you at the Meetup, 

Stephan & Florian & Anton 

Vienna - Austria

Tuesday, February 14 at 7:00 PM

4

https://www.meetup.com/Django-Vienna/events/237170245/

IoT Vienna - The Internet of Things Group of Vienna

Am 04.-06. Mai 2017 findet in Wien wieder die Linuxwoche (https://www.linuxwoch...) statt. Unsere Partnergruppe IoT Makers Vienna (http://www.meetup.com...) wollen auf dem Stand von IoT Austria mit dabei sein.

Wer mag von Euch bei der Vorbereitung und der Betreuung vor Ort helfen?

Bitte eine Mail an hello@iot-austria.at

Infos über das Event Team findet Ihr hier: https://www.iot-austr...

Wien - Austria

Thursday, May 4 at 9:00 AM

2

https://www.meetup.com/IoT-Vienna/events/237169043/

Docker is an incredibly popular tool for virtualizing development and production environments. Its value lies in the idea that it creates portable, scalable environments that anyone can scaffold within minutes. However, a consequence of virtualizing environments is that we have to take a different approach to testing them.

How do we effectively test Docker applications? This can be a loaded question. Its answer lies within a slightly different way of approaching testing. However, I believe Docker provides a variety of simple but powerful features that we can leverage to test any kind of application from both a current and historical point of view. I’d like to demonstrate these features from the perspective of a Dockerized Ruby on Rails application.

“How do we effectively test Docker applications? This can be a loaded question.”
Click To Tweet

Bringing Your Application into the Virtual Realm

Docker’s virtualization design has a bit of a weird learning curve to it. The gist of it involves taking something that seems physical (a bundled and working application) and abstracting it into a new kind of reality. Docker likes to refer to this newer reality as a container. What’s most interesting about this reality is that a container also can be composed of other smaller containers.

With this in mind, we can guarantee two things about our Docker ecosystem:

1. Our Rails app will exist within a single container
2. Our database and other services, will also exist in different containers.

Now, let’s implement our plan.

Formulating your Docker setup

Let’s begin by building the container that will house our Rails application. We’ll do this by creating a Dockerfile:

FROM ruby:2.3.3
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /myapp
WORKDIR /myapp
ADD Gemfile /myapp/Gemfile
ADD Gemfile.lock /myapp/Gemfile.lock
RUN bundle install

ADD . /myapp

Our Dockerfile‘s control flow looks something like this:

1. Pull from a pre-built container on Docker Hub. In our case, this Ruby container is built using Ubuntu.
2. Because we pulled in a prebuilt Ubuntu container, we’ll install a few more Ubuntu packages that are required for running Rails.
3. Create a directory in the virtualized container to mount the application on.
4. Add the Gemfile and Gemfile.lock of your existing application.
5. Run bundle install inside of your Docker container.

We can now build this container by running: docker build .. It might take a few minutes (depending on your internet connection). When the process successfully completes, you’ll have created a virtualized Docker environment containing your Rails application.

Next, we’ll move on to what will connect our application container to the rest of our ecosystem. This file is known as docker-compose.yml.

version: '2'
services:
  db:
    image: postgres
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db

Breaking down this file, we find that:

1. We’re declaring use of version 2 of Docker Compose’s file format. We want a file that’s relevant to the design decisions and formatting that is currently the standard. Read more on the file format here.
2. We’re defining two services: db and web.
3. db is made up of a prebuilt postgres image that contains an instance of PostgreSQL.
4. web is created by building our Dockerfile, configuring a command for docker-compose up, mounting the application to our big container, exposing ports for the app, and declaring a dependence on the db container.

When all of this is said and done, we will be able to run docker-compose up, and our whole application should be up and running (accessible under http://localhost:3000).

Running commands against a Docker container

Now that our app is Dockerized, we can start figuring out how to interact with its newly virtualized context. The first thing that’s different about our interactions is how we run basic command line commands against the Docker container. You’ll now need to run docker-compose run web before any commands that you want to execute against the app container.

This means that something like: rails g model user now becomes docker-compose run web rails g model user. The distinction is very important as we want to run the Rails commands against our Docker container, not our local environment.

Building off of the example presented above, to run your app’s test suite:

# Using Rspec? Run this.
docker-compose run web bundle exec rspec spec/[path_to_test]
# Using Minitest? Run this.
docker-compose run web bundle exec rake test/[path_to_test]

To help save our wrists from having to type a few more words every time, we can add an alias to our local environment. For me, I prefer creating the aliases docker-mini or docker-spec, depending on the testing framework I’m using.

alias docker-mini=docker-compose run web bundle exec rake alias docker-spec=docker-compose run web bundle exec rspec

!New Call-to-action

Utilizing Docker as a Key to the Past

Now that we can successfully run tests in our Docker container, let’s leverage Docker to test historical environments for our application. However, this begs the question: “Why would we need to even look at previous configurations of our application?”

Simply put, apps change over time. That’s no secret. If you think about smaller dependency changes, you can start to imagine how bugs could be introduced by doing something as simple as upgrading your database or Ruby version. To better track down errors and test the viability of our applications in certain environments, we can modify our Docker environments to simulate a previous iteration our application (one that runs Ruby 1.9.3).

Our starting point for doing this is going to be with docker-compose.yml:

version: ‘2’
services:
  db:
    image: postgres
  web:
    build:
      context: .
      dockerfile: dockefiles/Dockerfile-193
    command: bundle exec rails s -p 3000 -b ‘0.0.0.0’
    volumes:
      - .:/myapp
    ports:
      - “3000:3000”
    depends_on:
      - db

In this iteration, we’ve made the build section a bit more robust. We’re still building within the same context, but we’re specifying which Docker file we want to use for things.

Another thing that’s different is that I’m referring to a different Dockerfile. This `Dockerfile` contains a different configuration that is better suited for our historical testing. It looks something like this:

Dockerfile-193

FROM zedtux/ruby-1.9.3
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /myapp
WORKDIR /myapp
ADD Gemfile /myapp/Gemfile
RUN bundle install
ADD . /myapp

This Dockerfile-193 is different from our original Dockerfile in two different ways. One is the FROM source. We’re simply using a prebuilt Docker image that contains Ruby 1.9.3. The other change is the removal of adding the Gemfile.lock. The reason for this is that we’re going to have to regenerate our Gemfile.lock against Ruby 1.9.3. This, however, might get a little messy.

A few notes on downgrading dependencies

If you’ve got a historical Gemfile on hand, you’re probably good for most of this step. However, if you’re not as well prepared, we’re going to have to go through some raw trial and error to configure things.

The best dependency to change first is Rails. Since we’re trying to configure our application against Ruby 1.9.3, you’ll have to use Rails versions 4.0 and below.

Choose the version of Rails that you want to try rebuilding the container against. From here, it will be trial and error in seeing what dependencies throw install errors. It’d be useful to have RubyGems pulled up to check which versions are ideal for a specific gem and language version.

After this messy process is completed, you’ll have a proper Gemfile for a legacy configuration of your app. I recommend that you rename it Gemfile-193 and put it within your app under /gemfiles/. We can even leverage Docker to look for this folder in custom configurations.

dockerfiles/Dockerfile-193

FROM zedtux/ruby-1.9.3
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /myapp
WORKDIR /myapp
ADD Gemfile /myapp/gemfiles/1-93/Gemfile
RUN bundle install
ADD . /myapp

Now that we finally have a historical formula for a Ruby 1.9.3 version of our application, we can utilize the same process for testing the container as before. We’ll then be able to easily test and track down historical configuration issues in our application.

Wrapping Up

A lot of new code and concepts have been thrown at you during this article. Let them sit and simmer with you for a bit. There’s a good deal of trial and error involved with learning this process.

Once we work out the kinks in downgrading dependencies, Docker will have granted us a means to travel back in time to historical configurations with ease. With this, we’ll be able to run our test suite against different versions of the application. As our application grows, we can repeat this process and enable easiest historical testing as we grow.

We can use this history to find out how backwards-compatible a project might be. It also might be useful for being able to track down historical bugs in the application that could have been caused by configuration changes, a much-needed relief for the DevOps process. Either way, you now know how to leverage Docker for your personal and team needs.

“Effectively Testing Dockerized Ruby Applications” via @hiimtaylorjones
Click To Tweet

The post Dockerizing Ruby Applications and Effectively Testing Them appeared first on via @codeship.

Angular Vienna

Hi everybody!

This year we kickstart our first meetup with a special guest: Raquel Vèlez, tech lead of npm - https://twitter.com/r...t

I got in touch with her recently and could convince her to come to Vienna. She is happy to  give a talk about npm, an essential tool for all Angular developers but also NodeJS and Javascript developers in general.

To make things easy I got in touch with the other meetups and we agreed on the first joined meetup of ViennaJS and React and NodeJS and Angular to give everybody in the community the opportunity to see Raquels talk. Thanks a lot to the other meetup groups!

I know already - this will be pretty cool gathering! 😎

Talks: 

Giuseppe Gurgone
view-source: https://twitter.com...

An overview of twitter.com's front-end architecture. 

Raquel Vèlez

“So you want to write some software. And you decide to use npm, because everyone’s saying it’s the coolest thing ever. Great! But... where do you start? And once you’ve started, how do you take advantage of the advanced features? Let’s write an app together! Whether you’re brand new to using npm or have been using it for years, I guarantee you’ll learn a new trick or two - or at least get a good laugh!”

Sponsors:

Tapkey - www.tapkey.com

Tapkey is dedicated to the creation and proliferation of secure mobile access in a digitally connected world. The company’s patented Tapkey solution transforms smartphones into smart keys, making it easy for end users to take advantage of this liberating technology. And with its open platform, the company also makes it easy for channel partners to add Tapkey functionality to their products: Tapkey partners with lock-hardware manufacturers in diverse spaces, helping them build a broad portfolio of Tapkey-empowered solutions. For more information, visit

www.tapkey.com

Heia – www.heia-easy.com 

Heia's mission is to provide the most attractive web-booking and app solutions for hotels and student homes, embedding the latest technologies and innovations to create a unique customer experience and user handling. 

Being a joint venture between the companies Ameya and CCT Software Solutions, HEIA embodies vast experience in the hospitality industry combined with exclusive access to more than 1.500 hotels, among them many well-known luxury brands.

foryouandyourcustomers - 

www.foryouandyourcustomers.com 

For our foryouandyourcustomers location in Vienna we are looking for an experienced web developer (f/m), who, in addition to a pragmatic solution-oriented approach, also appreciates a sophisticated software architecture as the basis for efficient and clean implementation.

Kivu - http://www.kivu.tech...

Kivu Technologies provides clients in the security sector with a ground-breaking automated process to collect, process and analyse vast tracts of data at blazing speeds, while protecting privacy.

Established in 2016, Kivu is forging a new future for big data, disrupting the existing data management platforms and providing with clients with vital, intelligent and reliable real-time analysis. Kivu provides the answers to clients’ key questions, saving the analysts precious time and resources.

Vienna - Austria

Wednesday, January 25 at 7:00 PM

86

https://www.meetup.com/Angular-Vienna/events/236923547/

Docker just released version 1.13 of Docker Engine, which is full of new features to make deploying highly available services even easier. It also introduces some commands and workflows to improve the developer experience for Docker users. You can see the full release notes on GitHub, but here’s a summary of a handful of interesting updates.

“Here’s a summary of some of Docker 1.13’s most interesting updates.” via @rhein_wein
Click To Tweet

Orchestration updates

Docker 1.13 includes a handful of improvements and updates for running your services in Swarm Mode. You can now pin images by digest for rolling updates (which is more specific than tags), and your services have better logging during image pulls to reduce the amount of noise and logspam in the logs.

You’ll also see more visibility into errors for tasks scheduled on your Swarm cluster, including better error messages. The scheduling algorithms have been updated to distribute the same types of tasks a bit more evenly.

Let’s say you have two containers running service A and three containers running service B. The most undesirable situation is that in a two-node cluster, all containers running service A are scheduled on one node and all Service B containers are on the other. If one node goes down, one of the services is completely unavailable. Tweaks to the scheduler ensure that type of workload distribution is avoided.

A new prune command to keep your system healthy

If you’re like me, docker ps -a | grep 'Exited' | awk '{print $1}' | xargs docker rm (or the more extreme docker rm -f $(docker ps -aq)) and `docker rmi -f $(docker images -q) are commands you fire off multiple times a day to keep your workspace clean.

Docker 1.13 introduces the prune command, which helps you keep your system healthy and reduce the footprint of Docker by easily deleting unused resources. Running docker system prune will remove all stopped containers, unused images, and unused networks volumes in one fell swoop.

If you find the long rm commands more enjoyable, don’t worry, they still work, but prune makes it easier. I’ll get in the habit of using prune and keep those long commands in the same place in my brain where I store Doom cheat codes.

!New Call-to-action hbspt.cta.load(1169977, ‘224ef658-b146-4569-b00b-3c0ad87be198’, {});

Restructured CLI

Docker has grown a lot over the last few years, and each release adds something new and exciting to the CLI. Unfortunately, a side effect of this rapid development was a sometimes unwieldy CLI that was hard to understand for people new to Docker. In Docker 1.13, the CLI has been restructured to focus all commands on top-level resources. The biggest change is that you’ll find docker container as a management command for your containers. The old syntax will still work for now, but Docker encourages every user to start interacting with the CLI using the new management commands.

Build and caching improvements

Cache poisoning is a real threat, and beginning in version 1.10, Docker introduced features to protect your images from cache poisoning when using images pulled from remote registries. Before 1.10, the image layers pulled from a remote registry were not used when new images were built on the same host. However, this also applied to images you pull from a trusted source.

In Docker 1.13, you can use the new runtime flag --cache-from to specify that you want your image to be rebuilt using the image cache associated with an image pulled down from a remote registry. It’s up to you to decide whether the image cache is trustworthy and protect yourself against cache poisoning.

Additionally, docker build has two new flags: --compress and --squash. Compress will compress your build context when it’s sent to the daemon, which can speed up your image builds. The --squash flag is still experimental, and it will squash the image into one layer. This can simplify the build process a bit, but might make it harder to work with your images if you heavily rely on caching.

Docker Compose V3 syntax

Docker 1.13 includes something brand new — an updated and extended version of Docker Compose syntax. Labeled as V3, this syntax is a bit unique because it’s intended to be used to deploy Docker services to a Swarm cluster. It has a lot in common with V2 but should be treated as a separate domain language.

Using a V3 file, you can easily deploy to a Swarm cluster via docker stack deploy --compose-file=docker-compose.yml. V3 syntax can help unify your Docker Compose files and make it easier to switch between development and production environments. If you’re interested in the specifics of the V3 schema, the configuration is available in the docker/compose GitHub repo.

Want to tinker with 1.13? If you’re using Docker for Mac and Windows, you’ll be notified of an update. Otherwise, you can install Docker on any flavor of OS via the installation instructions in the documentation.

“What’s New in Docker 1.13” via @rhein_wein
Click To Tweet

The post What’s New in Docker 1.13 appeared first on via @codeship.

Vienna<-R

Christoph Fabianek: Crowd Intelligence

This talk covers predictions based on a diverse collection of independently deciding individuals using knitr for reporting and shiny to provide personalized analyses of survey participants.

For further comments and suggestions for projects and talks just drop a mail at 

host@viennar.org

We are looking forward to a fruitful/interesting/controversial discussion!

Greetings, 

ViennaR 

Vienna - Austria

Tuesday, February 28 at 7:00 PM

4

https://www.meetup.com/ViennaR/events/226325426/

Python User Group Austria

Programmers at all levels from beginner to expert are welcome!

We are still looking for talks - if you want to present something, please add yourself to the agenda on our wiki.

You can find the evening's program there as well.

Vienna - Austria

Thursday, January 26 at 6:00 PM

13

https://www.meetup.com/PYUGAT/events/237052752/

In the second post of this series, we continued with a quick tutorial on deploying new Docker images to Amazon’s EC2 Container Service with Codeship. We’ll wrap things up with a discussion about the similarities and differences of Amazon’s Elastic Beanstalk and CodeDeploy.

So, we’ve seen how to deploy Docker images to ECR, but what about Amazon’s other non-Docker code delivery methods?

“Discussing the similarities and differences between Elastic Beanstalk and CodeDeploy.”
Click To Tweet

Elastic Beanstalk and CodeDeploy are both very similar deployment products with one major difference: resource management.

AWS CodeDeploy is a service that automates code deployments to currently running EC2 instances. This is a similar solution to many atomic deployment services, as it does not provision resources or provide application-level monitoring.

Elastic Beanstalk, on the other hand, is a web application deployment service that can launch additional AWS resources (like load balancers and EC2 instances) and deploy code changes. Fortunately, getting set up with both Elastic Beanstalk and CodeDeploy deployments on Codeship is rather straightforward.

Because we already did the work of getting authentication working in the last post, the first real step of enabling CodeDeploy and Elastic Beanstalk deploys is adding the following service to your codeship-services.yml file:

This section defines a new Docker container using Codeship’s aws-deployment image, using our previously defined environment file, and mounts the project directory to a directory called /deploy within the container.

Mounting the current project directory within the container is important because the deployment service needs to be able to actually access the code it is to deploy.

Once we’ve defined the deployment service, we can then utilize it to deploy to both of these services with very little configuration. To enable Codeship deployments using CodeDeploy, add the following step to your codeship-steps.yml file:

Because Codeship already did all the work to actually facilitate CodeDeploy deployments, all it takes to push your code up to AWS is to plug a few parameters into the codeship_aws_codedeploy_deploy command:

• the CodeDeploy application name
• the deployment group name
• the S3 bucket to upload the artifact to

On the flip side, enabling Elastic Beanstalk deployments is just as simple. It also utilizes the awsdeployment service, but the command that is run in the codeship-steps.yml file changes a bit:

Just like the CodeDeploy example, all it takes to deploy to Elastic Beanstalk using Codeship are a few parameters:

• the Elastic Beanstalk application name
• the Elastic Beanstalk environment name
• the S3 bucket to upload the artifact to

While this process is incredibly straightforward, if you’d like to see a practical example of deploying an existing project to both of these services using Codeship, I’ve mirrored the code shown above onto a fork of the Lumen project. Just take a look at the codeship-services.yml and codeship-steps.yml files and you’ll see what I mean.

Conclusion

All three posts in this series have shown relatively basic examples of what can easily become a very complicated process. However, by using Codeship, even the most complex deployment process can be handled with only a little effort.

AWS isn’t an easy thing to learn; there are a lot of nuances that can take time to take in and understand. But with tools like Codeship, integrating your CI/CD process with AWS is surprisingly easy.

“AWS CodeDeploy + AWS Elastic Beanstalk” via @codeship
Click To Tweet

This has been Part Three of a series about seploying Docker apps to AWS. Want to read all three parts together? Download our free ebook, Deploying Docker Apps to AWS.

The post Setting Up Deployment for AWS CodeDeploy and AWS Elastic Beanstalk appeared first on via @codeship.

Vienna WordPress Meetup

We’re happy to announce that WordCamp Vienna 2017 is officially on the calendar!

WordCamp Vienna will be held on 22nd of April 2017 at the UNI Campus in the Altes AKH, Vienna. Contributor Day will be April 23rd. https://2017.vienna.w...

Get your ticket NOW – only €20 !

We’ll be keeping you posted on all the details over the coming months, including speaker submissions, sponsors and more!

Vienna - Austria

Saturday, April 22 at 9:00 AM

26

https://www.meetup.com/Vienna-WordPress-Meetup/events/237043013/

IoT Vienna - The Internet of Things Group of Vienna

Am 20. & 21. Mai 2017 findet in Wien wieder die MakerFaireVienna (http://www.makerfaire...) statt. Unsere Partnergruppe IoT Makers Vienna (http://www.meetup.com...) wollen auf dem Stand von IoT Austria mit dabei sein.

Wer mag von Euch bei der Vorbereitung und der Betreuung vor Ort helfen?

Bitte eine Mail an hello@iot-austria.at

Infos über das Event Team findet Ihr hier: https://www.iot-austr...

Vienna - Austria

Saturday, May 20 at 9:00 AM

1

https://www.meetup.com/IoT-Vienna/events/237042397/