Security updates have been issued by Debian (augeas, connman, fontforge, freeradius, git, mariadb-10.1, openjdk-7, php5, qemu, qemu-kvm, and tenshi), Fedora (augeas, libsndfile, thunderbird, and xen), Gentoo (AutoTrace and jbig2dec), Mageia (dbus, flash-player-plugin, groovy, groovy18, heimdal, kernel-linus, kmail(kdepimlibs4), libice, libmodplug, miniupnpc, and postgresql9.3/4/6), openSUSE (freeradius-server, gnome-shell, ImageMagick, and openvswitch), and SUSE (java-1_8_0-ibm, libzypp, and postgresql94).
Security updates have been issued by Debian (extplorer and libraw), Fedora (mingw-libsoup, python-tablib, ruby, and subversion), Mageia (avidemux, clamav, nasm, php-pear-CAS, and shutter), Oracle (xmlsec1), Red Hat (openssl tomcat), Scientific Linux (authconfig, bash, curl, evince, firefox, freeradius, gdm gnome-session, ghostscript, git, glibc, gnutls, groovy, GStreamer, gtk-vnc, httpd, java-1.7.0-openjdk, kernel, libreoffice, libsoup, libtasn1, log4j, mariadb, mercurial, NetworkManager, openldap, openssh, pidgin, pki-core, postgresql, python, qemu-kvm, samba, spice, subversion, tcpdump, tigervnc fltk, tomcat, X.org, and xmlsec1), SUSE (git), and Ubuntu (augeas, cvs, and texlive-base).
Security updates have been issued by CentOS (git), Debian (firefox-esr and mariadb-10.0), Gentoo (bind and tnef), Mageia (kauth, kdelibs4, poppler, subversion, and vim), openSUSE (fossil, git, libheimdal, libxml2, minicom, nodejs4, nodejs6, openjpeg2, openldap2, potrace, subversion, and taglib), Oracle (git and kernel), Red Hat (git, groovy, httpd24-httpd, and mercurial), Scientific Linux (git), and SUSE (freeradius-server, ImageMagick, and subversion).
Security updates have been issued by Arch Linux (firefox, flashplugin, lib32-flashplugin, libsoup, and varnish), Debian (freeradius, git, libsoup2.4, pjproject, postgresql-9.1, postgresql-9.4, postgresql-9.6, subversion, and xchat), Fedora (gsoap, irssi, knot-resolver, php-horde-horde, php-horde-Horde-Core, php-horde-Horde-Form, php-horde-Horde-Url, php-horde-kronolith, php-horde-nag, and php-horde-turba), Mageia (perl-XML-LibXML), Oracle (libsoup), Red Hat (firefox and libsoup), SUSE (kernel and libsoup), and Ubuntu (git, kernel, libsoup2.4, linux, linux-aws, linux-gke, linux-raspi2, linux-snapdragon, linux, linux-raspi2, linux-hwe, linux-lts-trusty, linux-lts-xenial, php5, php7.0, and subversion).
Security updates have been issued by Debian (firefox-esr), Fedora (cacti, community-mysql, and pspp), Mageia (varnish), openSUSE (mariadb, nasm, pspp, and rubygem-rubyzip), Oracle (evince, freeradius, golang, java-1.7.0-openjdk, log4j, NetworkManager and libnl3, pki-core, qemu-kvm, and X.org), Red Hat (flash-plugin), and Slackware (curl and mozilla).
Security updates have been issued by Debian (varnish), Fedora (gcc, gcc-python-plugin, libtool, mingw-c-ares, and php-PHPMailer), Red Hat (bash, curl, evince, freeradius, gdm and gnome-session, ghostscript, git, glibc, golang, GStreamer, gtk-vnc, kernel, kernel-rt, libtasn1, mariadb, openldap, openssh, pidgin, postgresql, python, qemu-kvm, qemu-kvm-rhev, samba, tigervnc and fltk, tomcat, and X.org X11 libraries), Slackware (gnupg), and Ubuntu (apache2, lxc, and webkit2gtk).
Security updates have been issued by Debian (apache2, enigmail, graphicsmagick, ipsec-tools, libquicktime, lucene-solr, mysql-5.5, nasm, and supervisor), Fedora (mingw-librsvg2, php-PHPMailer, and webkitgtk4), Mageia (freeradius, gdk-pixbuf2.0, graphicsmagick, java-1.8.0-openjdk, kernel, libmtp, libgphoto, libraw, nginx, openvpn, postgresql9.4, valgrind, webkit2, and wireshark), openSUSE (apache2, chromium, libical, mysql-community-server, and nginx), Oracle (kernel), Red Hat (chromium-browser and eap7-jboss-ec2-eap), Slackware (squashfs), and Ubuntu (linux-hwe and nss).
Security updates have been issued by Arch Linux (cacti and chromium), CentOS (tomcat), Debian (roundcube), Fedora (bind99, dhcp, freeradius, golang, mingw-poppler, minicom, php-symfony, and webkitgtk4), openSUSE (GraphicsMagick and the_silver_searcher), Oracle (tomcat), Scientific Linux (tomcat), SUSE (kernel), and Ubuntu (apache2 and freeradius).
Security updates have been issued by Arch Linux (c-ares, freeradius, gvim, lib32-libtiff, libtiff, pcre, rkhunter, and vim), Debian (apache2, evince, imagemagick, unattended-upgrades, and vim), Fedora (openldap, php, and poppler), Oracle (freeradius), SUSE (evince and systemd, dracut), and Ubuntu (apport, icu, and libtasn1-3).
Post Syndicated from Nathan Taber original https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/
This post and accompanying code was generously contributed by:
DevOps Cloud Architect
Deploying software updates in traditional non-containerized environments is hard and fraught with risk. When you write your deployment package or script, you have to assume that the target machine is in a particular state. If your staging environment is not an exact mirror image of your production environment, your deployment could fail. These failures frequently cause outages that persist until you re-deploy the last known good version of your application. If you are an Operations Manager, this is what keeps you up at night.
Increasingly, customers want to do testing in production environments without exposing customers to the new version until the release has been vetted. Others want to expose a small percentage of their customers to the new release to gather feedback about a feature before it’s released to the broader population. This is often referred to as canary analysis or canary testing. In this post, I introduce patterns to implement blue/green and canary deployments using Application Load Balancers and target groups.
If you’d like to try this approach to blue/green deployments, we have open sourced the code and AWS CloudFormation templates in the ecs-blue-green-deployment GitHub repo. The workflow builds an automated CI/CD pipeline that deploys your service onto an ECS cluster and offers a controlled process to swap target groups when you’re ready to promote the latest version of your code to production. You can quickly set up the environment in three steps and see the blue/green swap in action. We’d love for you to try it and send us your feedback!
Benefits of blue/green
Blue/green deployments are a type of immutable deployment that help you deploy software updates with less risk. The risk is reduced by creating separate environments for the current running or “blue” version of your application, and the new or “green” version of your application.
This type of deployment gives you an opportunity to test features in the green environment without impacting the current running version of your application. When you’re satisfied that the green version is working properly, you can gradually reroute the traffic from the old blue environment to the new green environment by modifying DNS. By following this method, you can update and roll back features with near zero downtime.
|A typical blue/green deployment involves shifting traffic between 2 distinct environments.|
This ability to quickly roll traffic back to the still-operating blue environment is one of the key benefits of blue/green deployments. With blue/green, you should be able to roll back to the blue environment at any time during the deployment process. This limits downtime to the time it takes to realize there’s an issue in the green environment and shift the traffic back to the blue environment. Furthermore, the impact of the outage is limited to the portion of traffic going to the green environment, not all traffic. If the blast radius of deployment errors is reduced, so is the overall deployment risk.
Containers make it simpler
Historically, blue/green deployments were not often used to deploy software on-premises because of the cost and complexity associated with provisioning and managing multiple environments. Instead, applications were upgraded in place.
Although this approach worked, it had several flaws, including the ability to roll back quickly from failures. Rollbacks typically involved re-deploying a previous version of the application, which could affect the length of an outage caused by a bad release. Fixing the issue took precedence over the need to debug, so there were fewer opportunities to learn from your mistakes.
Containers can ease the adoption of blue/green deployments because they’re easily packaged and behave consistently as they’re moved between environments. This consistency comes partly from their immutability. To change the configuration of a container, update its Dockerfile and rebuild and re-deploy the container rather than updating the software in place.
Containers also provide process and namespace isolation for your applications, which allows you to run multiple versions of them side by side on the same Docker host without conflicts. Given their small sizes relative to virtual machines, you can binpack more containers per host than VMs. This lets you make more efficient use of your computing resources, reducing the cost of blue/green deployments.
Fully Managed Updates with Amazon ECS
Amazon EC2 Container Service (ECS) performs rolling updates when you update an existing Amazon ECS service. A rolling update involves replacing the current running version of the container with the latest version. The number of containers Amazon ECS adds or removes from service during a rolling update is controlled by adjusting the minimum and maximum number of healthy tasks allowed during service deployments.
When you update your service’s task definition with the latest version of your container image, Amazon ECS automatically starts replacing the old version of your container with the latest version. During a deployment, Amazon ECS drains connections from the current running version and registers your new containers with the Application Load Balancer as they come online.
A target group is a logical construct that allows you to run multiple services behind the same Application Load Balancer. This is possible because each target group has its own listener.
When you create an Amazon ECS service that’s fronted by an Application Load Balancer, you have to designate a target group for your service. Ordinarily, you would create a target group for each of your Amazon ECS services. However, the approach we’re going to explore here involves creating two target groups: one for the blue version of your service, and one for the green version of your service. We’re also using a different listener port for each target group so that you can test the green version of your service using the same path as the blue service.
With this configuration, you can run both environments in parallel until you’re ready to cut over to the green version of your service. You can also do things such as restricting access to the green version to testers on your internal network, using security group rules and placement constraints. For example, you can target the green version of your service to only run on instances that are accessible from your corporate network.
When you’re ready to replace the old blue service with the new green service, call the ModifyListener API operation to swap the listener’s rules for the target group rules. The change happens instantaneously. Afterward, the green service is running in the target group with the port 80 listener and the blue service is running in the target group with the port 8080 listener. The diagram below is an illustration of the approach described.
Two services are defined, each with their own target group registered to the same Application Load Balancer but listening on different ports. Deployment is completed by swapping the listener rules between the two target groups.
The second service is deployed with a new target group listening on a different port but registered to the same Application Load Balancer.
By using 2 listeners, requests to blue services are directed to the target group with the port 80 listener, while requests to the green services are directed to target group with the port 8080 listener.
After automated or manual testing, the deployment can be completed by swapping the listener rules on the Application Load Balancer and sending traffic to the green service.
There are a few caveats to be mindful of when using this approach. This method:
- Assumes that your application code is completely stateless. Store state outside of the container.
- Doesn’t gracefully drain connections. The swapping of target groups is sudden and abrupt. Therefore, be cautious about using this approach if your service has long-running transactions.
- Doesn’t allow you to perform canary deployments. While the method gives you the ability to quickly switch between different versions of your service, it does not allow you to divert a portion of the production traffic to a canary or control the rate at which your service is deployed across the cluster.
While this type of deployment automates much of the heavy lifting associated with rolling deployments, it doesn’t allow you to interrupt the deployment if you discover an issue midstream. Rollbacks using the standard Amazon ECS deployment require updating the service’s task definition with the last known good version of the container. Then, you wait for Amazon ECS to schedule and deploy it across the cluster. If the latest version introduces a breaking change that went undiscovered during testing, this might be too slow.
With canary testing, if you discover the green environment is not operating as expected, there is no impact on the blue environment. You can route traffic back to it, minimizing impaired operation or downtime, and limiting the blast radius of impact.
This type of deployment is particularly useful for A/B testing where you want to expose a new feature to a subset of users to get their feedback before making it broadly available.
For canary style deployments, you can use a variation of the blue/green swap that involves deploying the blue and the green service to the same target group. Although this method is not as fast as the swap, it allows you to control the rate at which your containers are replaced by adjusting the task count for each service. Furthermore, it gives you the ability to roll back by adjusting the number of tasks for the blue and green services respectively. Unlike the swap approach described above, connections to your containers are drained gracefully. We plan to address canary style deployments for Amazon ECS in a future post.
With AWS, you can operationalize your blue/green deployments using Amazon ECS, an Application Load Balancer, and target groups. I encourage you to adapt the code published to the ecs-blue-green-deployment GitHub repo for your use cases and look forward to reading your feedback.
If you’re interested in learning more, I encourage you to read the Blue/Green Deployments on AWS and Practicing Continuous Integration and Continuous Delivery on AWS whitepapers.
If you have questions or suggestions, please comment below.
Security updates have been issued by CentOS (freeradius, kernel, and mercurial), Debian (libarchive and mercurial), Fedora (chromium-native_client, systemd, and tomcat), Mageia (drupal, golang, libmwaw, libsndfile, rxvt-unicode, and tomcat), Oracle (kernel), Slackware (bind, httpd, kernel, and libgcrypt), SUSE (bind, clamav, kernel, and openvpn-openssl1), and Ubuntu (bind9, eglibc, and linux-hwe).
Security updates have been issued by Arch Linux (apache and libnl), CentOS (mercurial), Debian (drupal7), Fedora (c-ares), Oracle (freeradius and kernel), Scientific Linux (kernel), SUSE (php53 and xen), and Ubuntu (kernel, linux, linux-aws, linux-gke, linux-raspi2, linux-snapdragon, linux, linux-raspi2, linux-lts-trusty, and linux-lts-xenial).
Security updates have been issued by Arch Linux (expat and poppler), Debian (unrar-nonfree and vlc), Fedora (chromium and mercurial), Gentoo (freeradius, kauth, and libreoffice), Mageia (glibc, irssi, kernel, kernel-linus, kernel-tmb, and rpcbind/libtirpc), openSUSE (libgcrypt, netpbm, and sudo), Oracle (sudo), Scientific Linux (mercurial), Slackware (kernel), SUSE (jakarta-taglibs-standard, kernel, and kernel-source), and Ubuntu (apache2).
Security updates have been issued by Arch Linux (glibc and lib32-glibc), CentOS (glibc and kernel), Debian (eglibc, kernel, and libffi), openSUSE (exim, freeradius-server, libxml2, Mozilla based packages, and xorg-x11-server), Oracle (glibc and kernel), Scientific Linux (glibc and kernel), SUSE (glibc, kernel, and openvpn), and Ubuntu (eglibc, glibc, exim4, libnl3, linux, linux-meta, linux-aws, linux-meta-aws, linux-gke, linux-meta-gke, linux-hwe, linux-meta-hwe, linux-lts-xenial, linux-meta-lts-xenial, linux-meta-raspi2, linux-raspi2, and linux-meta-snapdragon, linux-snapdragon).
Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/estefannie-gopro-selfie/
Are you tired of having to take selfies physically? Do you only use your GoPro for the occasional beach vacation? Are you maybe even wondering what to do with the load of velcro you bought on a whim? Then we have good news for you: Estefannie‘s back to help you out with her Personal Automated GPS-Controlled Portable Photo Taker…PAGCPPT for short…or pagsssspt, if you like.
Hey World! Do you like vacation pictures but don’t like taking them? Make your own Personal Automated GPS Controlled Portable Photo Taker! The code, components, and instructions are in my Hackster.io account: https://www.hackster.io/estefanniegg/automated-gps-controlled-photo-taker-3fc84c For this build, I decided to put together a backpack to take pictures of me when I am close to places that like.
The Personal Automated GPS-Controlled Portable Photo Taker
Try saying that five times in a row.
Go on. I’ll wait.
Using a Raspberry Pi 3, a GPS module, a power pack, and a GoPro plus GoPro Stick, Estefannie created the PAGCPPT as a means of automatically taking selfies at pre-specified tourist attractions across London.
With velcro and hot glue, she secured the tech in place on (and inside) a backpack. Then it was simply a case of programming her set up to take pictures while she walked around the city.
Making the GoPro…go
Estefannie made use of a GoPro API library to connect her GoPro to the Raspberry Pi via WiFi. With the help of this library, she wrote a Python script that made the GoPro take a photograph whenever her GPS module placed her within a ten-metre radius of a pre-selected landmark such as Tower Bridge, Abbey Road, or Platform 9 3/4.
The full script, as well as details regarding the components she used for the project, can be found on her hackster.io page here.
Estefannie Explains it All
You’ll have noticed that we’ve covered Estefannie once or twice before on the Raspberry Pi blog. We love project videos that convey a sense of ‘Oh hey, I can totally build one of those!’, and hers always tick that box. They are imaginative, interesting, quirky, and to be totally honest with you, I’ve been waiting for this particular video since she hinted at it on her visit to Pi Towers in May. I got the inside scoop, yo!
What’s better than taking pictures? Not taking pictures. But STILL having pictures. I made a personal automated GPS controlled Portable Photo Taker ⚡ NEW VIDEO ALERT⚡ Link in bio.
1,351 Likes, 70 Comments – Estefannie Explains It All (@estefanniegg) on Instagram: “What’s better than taking pictures? Not taking pictures. But STILL having pictures. I made a…”
Make sure to follow her on YouTube and Instagram for more maker content and random shenanigans. And if you have your own maker social media channel, YouTube account, blog, etc, this is your chance to share it for the world to see in the comments below!
Security updates have been issued by Arch Linux (irssi, lib32-libtasn1, and wireshark-cli), Debian (libmwaw, otrs2, and tor), Fedora (ansible, freeradius, gnutls, mingw-poppler, mosquitto, oniguruma, perltidy, picocom, systemd, and wget), Mageia (ansible, dropbear, gajim, libsndfile, libxslt, lxc, zoneminder, and zziplib), openSUSE (ffmpeg, libnettle, mysql-connector-cpp, mysql-workbench, and wireshark), and Ubuntu (irssi).