Sunday, June 18, 2017

DevCentral Cloud Month - Week Four

What’s this week about?


Ready for another week of Cloud Month on DevCentral? Suzanne, Hitesh, Greg, Marty and Lori are ready! Last week we looked at services, security, automation, migration, Ansible and other areas to focus on once you get your cloud running. We also had a cool Lightboard Lesson explaining BIG-IP in the public cloud. This week we go deeper into areas like high availability, scalability, responsibility, inter-connectivity and exploring the philosophy behind cloud deployment models.

Now that we’re half-way through Cloud Month, I thought it’d be fun to share a little bit about our authors.

Suzanne Selhorn is a Sr. Technical Writer with our TechPubs team. Our Technical Communications team are responsible for many of the deployment guides you use and are also the creators of some of the awesome step-by-step technical videos featured on DevCentral’s YouTube channel. She and Thomas Stanley crafted the AWS series.

Hitesh Patel is a Sr. Solution Architect covering Cloud/DevOps. He’s one of the smartest cloud cookies we got and works with F5 customers to get a handle on their cloud deployments. He also loves karaoke.

Greg Coward is a Solution Architect on our Business Development team. The BizDev team works with our many technology partners building out joint solutions. Greg covers Microsoft and how BIG-IP plays in Azure among other solutions.

Marty Scholes is an Applications Architect with our Solutions Marketing team. Traditionally, he writes whitepapers, technical articles and helps the Marketing team understand the technical nuances of various solutions and this month he went deep into GoogleCloud deployments.

Finally, someone you probably are already familiar due to her extensive writing and expertise, F5’s Principal Technical Evangelist Lori MacVittie. User 38 on DevCentral, she is a subject matter expert on emerging technologies and how F5 fits with the internet craze these days. I’ve been fortunate to have known & worked with Lori since her early days at F5 when we were both trailblazing Technical Marketing Managers.

The DevCentral team truly appreciates their contributions to Cloud Month and encourages you to connect with them.


ps

Sunday, June 11, 2017

DevCentral Cloud Month - Week Three

We hope you’re enjoying DevCentral’s Month thus far and Suzanne, Hitesh, Greg, Marty and Lori ready to go again this week. Last week we got you deployed in AWS and Kubernetes, learned the basics of Azure, got knee-deep in Cloud/Automated architectures and celebrated SOA’s survival. Now that your cloud is installed and running, this week we look at things like security, migration, services, automation and the challenges of data management.

Monday, Suzanne will help you secure your new AWS application with a F5 WAF; Tuesday, Hitesh will explore the Services Model for cloud architectures; Wednesday, Greg gets into Deployment Scenarios for BIG-IP in Azure; if you thought 24 minutes was quick, on Thursday Marty shows how to deploy an app into Kubernetes even faster; and Lori and her infinite cloud wisdom, wonders if the technical and data integration challenges from 10 years ago (100 in technology years) still exist for #Flashback Friday.

Great content so far and if you need to catch up or see what's coming, check out our Cloud Month Calendar.


ps

Monday, June 5, 2017

DevCentral Cloud Month - Week Two

What's this week about?

You got a mini taste of DevCentral’s Cloud Month last week and week two we really dig in. This week we’re looking at Build and Deployment considerations for the Cloud. The first step in successfully deploying in a cloud infrastructure. Starting today, Suzanne and team show us how to deploy an application in AWS; On Wednesday, Greg, harking the Hitchhiker’s Guide, explains Azure’s Architectural Considerations; Marty uncovers Kubernetes concepts and how to deploy an application in Kubernetes this Thursday; on #Flashback Friday, Lori takes us down memory lane wondering if SOA is still super. Filling my typical Tuesday spot, Hitesh reveals some foundational building blocks of F5’s cloud/automated architectures.
These will help get you off the ground and your head in the clouds, preferably Cloud Nine.
Enjoy!
ps
Related:

Thursday, June 1, 2017

Cloud Month on F5 DevCentral

#DCCloud17

The term ‘Cloud’ as in Cloud Computing has been around for a while. Some insist Western Union invented the phrase in the 1960s; others point to a 1994 AT&T ad for the PersonaLink Services; and still others argue it was Amazon in 2006 or Google a few years later. And Gartner had Cloud Computing at the top of their Hype Cycle in 2009.

No matter the birth year, Cloud Computing has become an integral part of an organization’s infrastructure and is not going away anytime soon. A 2017 SolarWinds IT Trends report says 95% of businesses have migrated critical applications to the cloud and F5's SOAD report notes that 20% of organizations will have over half their applications in the cloud this year. It is so critical that we’ve decided to dedicate the entire month of June to the Cloud.

We’ve planned a cool cloud encounter for you this month. We’re lucky to have many of F5’s Cloud experts offering their 'how-to' expertise with multiple 4-part series. The idea is to take you through a typical F5 deployment for various cloud vendors throughout the month. Mondays, we got Suzanne Selhorn & Thomas Stanley covering AWS; Wednesdays, Greg Coward will show how to deploy in Azure; Thursdays, Marty Scholes walks us through Google Cloud deployments including Kubernetes.

But wait, there’s more!

On Tuesdays, Hitesh Patel is doing a series on the F5 Cloud/Automation Architectures and how F5 plays in the Service Model, Deployment Model and Operational Model - no matter the cloud and on F5 Friday #Flashback starting tomorrow, we’re excited to have Lori MacVittie revisit some 2008 #F5Friday cloud articles to see if anything has changed a decade later. Hint: It has…mostly. In addition, I’ll offer my weekly take on the tasks & highlights that week.

Below is the calendar for DevCentral's Cloud Month and we’ll be lighting up the links as they get published so bookmark this page and visit daily! Incidentally, I wrote my first Cloud tagged article on DevCentral back in 2009. And if you missed it, Cloud Computing won the 2017 Preakness. Cloudy Skies Ahead!

June 2017

Monday Tuesday Wednesday Thursday Friday
28 29 30 31 ​ 1  ​

Cloud Month Intro & Calendar
2

Flashback Friday: The Many Faces of Cloud

Lori MacVittie
3
4 5

Successfully Deploy Your Application in the AWS Public Cloud

Suzanne Selhorn
6

Cloud/Automated Systems need an Architecture

Hitesh Patel
7

The Hitchhiker’s Guide to BIG-IP in Azure

Greg Coward
8  ​

Deploy an App into Kubernetes in less than 24 Minutes

Marty Scholes
9

F5 Flashback Friday: The Death of SOA Has (Still) Been Greatly Exaggerated

-Lori
10
11 12  ​

Secure Your New AWS Application with an F5 Web Application Firewall

-Suzanne
13  ​

The Service Model for Cloud/Automated Systems Architecture

-Hitesh


DCCloud17 X-tra!
14

The Hitchhiker’s Guide to BIG-IP in Azure – ‘Deployment Scenarios’

-Greg


DCCloud17 X-tra!
15  ​

Deploy an App into Kubernetes Even Faster (Than Last Week)

-Marty
16  ​

F5 Flashback Friday: Cloud and Technical Data Integration Challenges Waning

-Lori
17
18 19

Shed the Responsibility of WAF Management with F5 Cloud Interconnect

-Suzanne
20  ​

The Deployment Model for Cloud/Automated Systems Architecture

-Hitesh
21  ​

The Hitchhiker’s Guide to BIG-IP in Azure – ‘High Availability’

-Greg

DCCloud17 X-tra!

LBL Video: BIG-IP in the Private Cloud 
22  ​

Deploy an App into Kubernetes Using Advanced Application Services

-Marty
23  ​

Flashback Friday: Is Vertical Scalability Still Your Problem?

-Lori
24
25 26  ​

Get Back Speed and Agility of App Development in the Cloud with F5 Application Connector

-Suzanne
27

The Operational Model for Cloud/Automated Systems Architecture

-Hitesh
28

The Hitchhiker’s Guide to BIG-IP in Azure – ‘Life Cycle Management’

-Greg
29

Peek under the Covers of your Kubernetes Apps

-Marty
30

Cloud Month Wrap!

Titles subject to change...but not by much.

ps

Tuesday, May 23, 2017

Device Discovery on BIG-IQ 5.1

The first step in using a BIG-IQ to manage BIG-IP devices

BIG-IQ enables administrators to centrally manage BIG-IP infrastructure across the IT landscape. BIG-IQ discovers, tracks, manages, and monitors physical and virtual BIG-IP devices - in the cloud, on premise, or co-located at your preferred datacenter.

Let’s look at how to get BIG-IQ 5.1 to gather the information needed to start managing a BIG-IP device. This gathering process is called Device Discovery.

To get started, the first thing is to logon to the BIG-IQ

Once in, the first thing you do is let the BIG-IQ know about the BIG-IP device that you want to manage. Here, in Device Management>Inventory>BIG-IP Devices, we’ll click Add Device.

Here we’ll need the IP address, user name and password of the device you want to manage. If the device you want to manage is part of a BIG-IP Device Service Cluster (DSC), you’ll probably want to manage that part of its configuration by adding it to a DSC group on the BIG-IQ. After selecting a DSC, tell the BIG-IQ how to handle synchronization when you deploy configuration changes so that when you deploy changes to one device, the other DSC members get the same changes. Best practice is to let BIG-IQ do the sync.

Next click Add at the bottom of the page to start the discovery process.

Once the device recognizes your credentials, it’ll prompt you to choose the services that you want to manage. You always select LTM, even if you only mange other services because the other services depend on LTM. To finish the device discovery task, click Discover.

The BIG-IQ gathers the information it needs for each of the services you requested. This first step takes only a few moments while the BIG-IQ discovers your devices. You are done with discovery once the status update reads, Complete import tasks.

Now, we need to import the service configurations that the BIG-IQ needs before we can start managing that BIG-IP device. Click the link that says, Complete import tasks.

Next, you’ll begin the process of importing the BIG-IP LTM services for this device. Just like the discovery task, you’ll import LTM first.

Click Import.

This could take a little time depending on how many LTM objects are defined on this BIG-IP device. When the import finishes, BIG-IQ will display the date and time of when the operation was completed.

Now, we repeat the process for the second service provisioned on this device.

Importing an access device like BIG-IP APM is slightly different. Part of the import task is to identify the Access Group that this device uses to share its configuration. Whether you’re adding to an existing or creating a new access group, when you’re done entering the name of the group, click Add to start the import process. Here again, the time to process depends on how many BIG-IP APM configuration objects are defined on the device.

When the BIG-IP APM services import finishes and the time completed displays, you can simply click Close to complete the task.

You can now see that the device has been added to BIG-IQ.

That’s it! Now you can start managing the BIG-IP LTM and APM object on this device. For this article, we only imported LTM and APM objects but the process is the same for all services you manage.

Thanks to our TechPubs group and watch the video demo here.

ps

Related:

Tuesday, May 16, 2017

Updating an Auto-Scaled BIG-IP VE WAF in AWS

Update servers while continuing to process application traffic.


Recently we've been showing how to deploy BIG-IP (and F5 WAF) in various clouds like Azure and AWS.

Today, we’ll take a look at how to update an AWS auto-scaled BIG-IP VEweb application firewall (WAF) that was initially created by using this F5 github template. This solution implements auto-scaling of BIG-IP Virtual Edition (VE) Web Application Firewall (WAF) systems in Amazon Web Services. The BIG-IP VEs have the Local Traffic Manager (LTM) and Application Security Manager (ASM) modules enabled to provide advanced traffic management and web application security functionality. As traffic increases or decreases, the number of BIG-IP VE WAF instances automatically increases or decreases accordingly.

Prerequisites:


So, let’s assume you used the CFT to create a BIG-IP WAF in front of your application servers…and your business is so successful that you need to be able to process more traffic. You do not need to tear down your deployment and start over – you can make changes to your current deployment while the WAF is still running and protecting your environment.

For this article, a few examples of things you can change include increasing the throughput limit. For instance, When you first configured the WAF, you choose a specific throughput limit for BIG-IP. You can update that. You may also have selected a smaller AWS instance size and now want to choose a larger AWS instance type and add more CPU. Or, you may have set up your auto-scaling group to launch a maximum of two instances and now you want to be able to update the auto-scaling group attributes and add three.

This is all possible so let’s check it out.

The first thing we want to do is connect to one of the BIG-IP VE instances and save the latest configuration. We open putty, login and run the TMSH command (save /sys ucs /var/tmp/original.ucs) to save the UCS config file.

Then we use WinSCP to copy the UCS files to the desktop. You can use whatever application you like and copy the file wherever you like as this is just a temporary location.

Once that’s done, open the AWS Management Console and go to the S3 bucket. This bucket was created when you first deployed the CFT and locate yours.

When you find your file, click it and then click the Backup folder.

Once there, now upload the UCS file into that folder.

The USC is now in the folder.

The last step is to redeploy the CFT and change the selected options. From the main AWS Management Console, click CloudFormation, select your Stack and under Actions, click Update Stack.

Next, you can see the template we originally deployed and to update, click Next.

Scroll down the page to Instance Configuration to change the instance type size.

Right under that is Maximum Throughput to update the throughput limit.

And a little further down under Auto Scaling Configuration is where you can update the max number of instances. When done click Next at the bottom of the page.

It’ll ask you to review and confirm the changes. Click Update.

You can watch the progress and if your current BIG-IP VE instance is actively processing traffic, it will remain active until the new instance is ready.  Give it a little time to ensure the new instance is up and added to the auto scaling group before we terminate the other instance.

When it is done, we’ll confirm a few things.

Go to the EC2 Dashboard and check the running instances. We can see the old instance is terminated and the new instance is now available. You can also check the instance size and within the auto scaling group you can see the new maximum for number of instances.

And we’re deployed.

You can follow this same workflow to update other attributes of your F5 WAF. This allows you to update your servers while continuing to process traffic.

Thanks to our TechPubs group, you can also watch the video demo.

ps

Related:

Wednesday, May 10, 2017

Lightboard Lessons: What is BIG-IP?

In the early days of F5, BIG/IP was our original load balancer. Today, BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions.

In this Lightboard Lesson, I light up the various BIG-IP modules and what they do.



ps

Related:

Tuesday, May 9, 2017

Deploying F5’s Web Application Firewall in Microsoft Azure Security Center

Use F5’s Web Application Firewall (WAF) to protect web applications deployed in Microsoft Azure.

Applications living in the Cloud still need protection. Data breaches, compromised credentials, system vulnerabilities, DDoS attacks and shared resources can all pose a threat to your cloud infrastructure. The Verizon DBIR notes that web application attacks are the most likely vector for a data breach attack. While attacks on web applications account for only 8% of reported incidents, according to Verizon, they are responsible for over 40% of incidents that result in a data breach. A 2015 survey found that 15% of logins for business apps used by organizations had been breached by hackers.

One way to stay safe is using a Web Application Firewall (WAF) for your cloud deployments.

Let’s dig in on how to use F5’s WAF to protect web applications deployed in Microsoft Azure. This solution builds on BIG-IP Application Security Manager (ASM) and BIG-IP Local Traffic Manager (LTM) technologies as a preconfigured virtual service within the Azure Security Center.

Some requirements for this deployment are:
  • You have an existing web application deployed in Azure that you want to protect with BIG-IP ASM
  • You have an F5 license token for each instance of BIG-IP ASM you want to use

To get started, log into your Azure dashboard and on the left pane, toward the bottom, you’ll see Security Center and click it.


Next, you’ll want to click the Recommendations area within the Security Center Overview.


And from the list of recommendations, click Add a web application firewall.


A list of available web applications opens in a new pane. From the application list, select the application you want to secure.


And from there click Create New. You’ll get a list of available vendors’ WAFs and choose F5 Networks.


A new page with helpful links and information appears and at the bottom of the page, click Create.


First, select the number of machines you want to deploy – in this case we’re deploying two machines for redundancy and high availability. Review the host entry and then type a unique password for that field. When you click Pricing Tier, you can get info about sizing and pricing. When you are satisfied, at the bottom of that pane click OK.


Next, in the License token field, copy and paste your F5 license token. If you are only deploying one machine, you’ll only see one field. For the Security Blocking Level, you can choose Low, Medium or High. You can also click the icon for a brief description of each level. From the Application Type drop down, select the type of application you want to protect and click OK (at the bottom of that pane).


Once you see two check marks, click the Create button.


Azure then begins the process of the F5 WAF for your application. This process can take up to an hour. Click the little bell notification icon for the status of the deployment.


You’ll receive another notification when the deployment is complete.


After the WAF is successfully deployed, you’ll want to test the new F5 WAF and finalize the setup in Azure including changing the DNS records from the current server IP to the IP of the WAF.
When ready, click Security Center again and the Recommendations panel. This time we’ll click Finalize web application firewall setup.


And click your Web application.


Ensure your DNS settings are correct and check the I updated my DNS Settings box and when ready, click Restrict Traffic at the bottom of the pane.


Azure will give you a notification that it is finalizing the WAF configuration and settings, and you will get another notification when complete.


And when it is complete, your application will be secured with F5’s Web Application Firewall.
Check out the demo video and rest easy, my friend.
ps
Related:

Tuesday, May 2, 2017

DevCentral’s Featured Member for May – NTT Security’s Leonardo Souza

Leonardo Souza lives in the United Kingdom, with his partner, 5-year-old daughter, and a (very) recently newborn son. He’s Brazilian and lived in Portugal for quite a while. He then moved to UK about 5 years ago ‘because of the amazing weather,’ he jokes.

Leonardo started to work with computers when he was 18 years old (he’s not 18 anymore), so he’s worked with many technologies. Fast forward a bit (he’s not that old) and while working as a network engineer, he was working on a project to migrate applications from Alteon load balancers to F5 BIG-IP LTMs. He completed his LTM Essentials and LTM Advanced training during that time (2011) and with the migration project, he was impressed with BIG-IP.

He even applied for a job at F5 in 2012 and joined as a Network Support Engineer. That moved him from Portugal to UK, and has been doing F5 products exclusively ever since.

With all that, Leonardo is DevCentral’s Featured Member for May and we got a chance to talk with Leonardo about his life, work and scripting prowess.

DevCentral: You were an F5er from 2012-15 and continue to be a very active contributor in the DevCentral community. What keeps you involved?
Leonardo: I often say that 1 year in F5 support is equal to 5 years as a F5 customer.
While in F5 support, I had multiple technical challenges every day, and I would typically go to DevCentral to check iRules documentation and get ideas for uncommon cases. After I left F5, I started using DevCentral to stay up to date about what is going on in the F5 world by reading the DevCentral articles. Then I started to go there daily and answer some questions myself. 
Short answer: to keep me updated, both about F5 news and my F5 knowledge.
DC: Tell us a little about the areas of BIG-IP expertise you have.
LS: Is difficult to know all F5 products, because some are for very specific networks/scenarios, but I know the common ones:
BIG-IP BIG-IP LTM, GTM/DNS, AFM, APM, ASM, EM, BIG-IQ, and iRules.
I had been a little bit lazy about the F5 certifications but recently I have done all level 300 exams. I have started study for the 401, so that should be done in the next couple months.
DC: As a Security Consultant at NTT Security, what’s your typical workday?
LS: First to clarify, the company recently changed names from NTT Com Security to NTT Security. 
I work in professional services, doing projects that use F5 products. My daily work includes doing some pre-sales activities advising pre-sales team about the F5 products, doing projects, and finding solutions or writing scripts to automate some F5 tasks.
DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.
LS: I have been using DevCentral for many years, and iRules, to a point where it is part of my daily job. Flexibility is a major advantage for F5 and people ask all the time “Can you do this with an iRule?” 
Recently, I was working in a project to upgrade many F5 devices. We had to perform an extensive inventory for each device which was taking about 3 days per device. I wrote a Python script using iControl SOAP to perform that task. (I still prefer bash script, but there is no iControl SOAP for bash) 
It would take around 240 days to do that manually, and we did in around 3 days using the script.
DC: Finally, if you weren’t in technology – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?
LS: I am doing the job I wanted since I was young and I can’t picture myself doing any other type of job.

Thanks Leonardo! Check out all Leonardo’s DevCentral contributions or connect with him on LinkedIn. And visit NTT Security on the web or follow on Twitter and LinkedIn.

Tuesday, April 25, 2017

Configure HA Groups on BIG-IP

Last week we talked about how HA Groups work on BIG-IP and this week we’ll look at how to configure HA Groups on BIG-IP.

To recap, an HA group is a configuration object you create and assign to a traffic group for devices in a device group. An HA group defines health criteria for a resource (such as an application server pool) that the traffic group uses. With an HA group, the BIG-IP system can decide whether to keep a traffic group active on its current device or fail over the traffic group to another device when resources such as pool members fall below a certain level.

First, some prerequisites:
  • Basic Setup: Each BIG-IP (v13) is licensed, provisioned and configured to run BIG-IP LTM
  • HA Configuration: All BIG-IP devices are members of a sync-failover device group and synced
  • Each BIG-IP has a unique virtual server with a unique server pool assigned to it
  • All virtual addresses are associated with traffic-group-1
To the BIG-IP GUI!

First you go to System>High Availability>HA Group List>and then click the Create button.
The first thing is to name the group. Give it a detailed name to indicate the object group type, the device it pertains to and the traffic group it pertains to. In this case, we’ll call it ‘ha_group_deviceA_tg1.’
Next, we’ll click Add in the Pools area under Health Conditions and add the pool for BIG-IP A to the HA Group which we’ve already created. We then move on to the minimum member count. The minimum member count is members that need to be up for traffic-group-1 to remain active on BIG-IP A. In this case, we want 3 out of 4 members to be up. If that number falls below 3, the BIG-IP will automatically fail the traffic group over to another device in the device group.
Next is HA Score and this is the sufficient threshold which is the number of up pool members you want to represent a full health score. In this case, we’ll choose 4. So if 4 pool members are up then it is considered to have a full health score. If fewer than 4 members are up, then this health score would be lower. We’ll give it a default weight of 10 since 10 represents the full HA score for BIG-IP A. We’re going to say that all 4 members need to be active in the group in order for BIG-IP to give BIG-IP A an HA score of 10. And we click Add.
We’ll then see a summary of the health conditions we just specified including the minimum member count and sufficient member count. Then click Create HA Group.
Next, we go to Device Management>Traffic Groups>and click on traffic-group-1.
Now, we’ll associate this new HA Group with traffic-group-1. Go to the HA Group setting and select the new HA Group from the drop-down list. And then select the Failover Method to Device with the Best HA Score. Click Save.
Now we do the same thing for BIG-IP B. So again, go to System>High Availability>HA Group List>and then click the Create button. Give it a special name, click Add in the Pools area and select the pool you’ve already created for BIG-IP B. Again, for our situation, we’ll specify a minimum of 3 members to be up if traffic-group-1 is active on BIG-IP B. This minimum number does not have to be the same as the other HA Group, but it is for this example. Again, a default weight of 10 in the HA Score for all pool members. Click Add and then Create HA Group for BIG-IP B.
And then, Device Management>Traffic Groups> and click traffic-group-1. Choose BIG-IP B’s HA Group and select the same Failover method as BIG-IP A – Based on HA Score. Click Save.
Lastly, you would create another HA Group on BIG-IP C as we’ve done on BIG-IP A and BIG-IP B. Once that happens, you’ll have the same set up as this:
As you can see, BIG-IP A has lost another pool member causing traffic-group-1 to failover and the BIG-IP software has chosen BIG-IP C as the next active device to host the traffic group because BIG-IP C has the highest HA Score based on the health of its pool.

Thanks to our TechPubs group for the basis of this article and check out a video demo here.

ps