If you have ever worked on software development, you know that the gap between “it is working on my laptop” to “it is deployed on the cloud” can be like crossing a chasm of epic proportions! So many details to take care of. Is there capacity? Is the network configured correctly? What URL will I use? Is the middleware in place? Is logging setup? Can I scale? Are all the runtimes I need available?
The list can go on and on.
One of the benefits of PaaS is that a whole swathe of complex detail is taken care of by the platform itself, enabling the developer to know that the application will be deployed correctly and in a supportable manner.
But you may have wondered what is actually happening when you deploy your app—what is the process? What is going on?
In this episode, we take a journey into what the process entails and give you a taste of how easy it can be.
PLAY EPISODE #11
RESOURCES:
- Find more episodes of All Things Pivotal podcast
- Feedback: podcast@pivotal.io
- Subscribe to this feed
- Links Referred to in the Show:
Transcript
Speaker 1:
Welcome to the All Things Pivotal Podcast, the podcast of the intersection of agile, cloud, and big data. Stay tuned for regular updates, technical deep dives, architecture discussions, and interviews. Please share your feedback with us by emailing podcast@pivotal.io.
Simon Elisha:
Hello everyone and welcome back to the All Things Pivotal Podcast. Great to have you back. My name is Simon Elisha, CTO and Senior Manager of Field Engineering here in beautiful Australia and New Zealand, obviously not in the same one at the same time but I spend some time in each. Great to have you back for another episode and this one’s going to be a little more technical, not too deep, but deep enough, and today we’re going to talk about how you push an application into Pivotal CF. How do you deploy an application onto Cloud Foundry? What are the steps, what are the preconditions, what are the things you need to look out for? Et cetera.
It’s not difficult, which is a concept of having a platform with a service but I know for a lot of people, they’re trying to conceptualize what it looks like, what I would do, how I would do it. Let’s get into it. The first thing we need to think about are just a couple of things that might be a different when deploying into the cloud in general and onto a platform with a service in particular that you need to consider with regard to application. This is particularly important if you’re trying to bring a non-cloud-ready application across, so just a few preconditions.
The first thing that is the big no-no is writing to the local file system. Your application should not do that. It can do that if the information is short-lived, a temporary table or something that’s a working set, et cetera, but you must always remember that local disk can disappear at any time because those cloud resources can disappear at any time, so do not write anything that you want to get back in any reliable sense to the local file system.
Similarly, the instances that are running for your application do not share any storage together, so using that shared file system is an interconnect mechanism or an exchange mechanism is not a good [pattern 00:02:10] to use. What do you do instead? You use a dedicated service that is meant to share data. This could be a database, it could be a blog store, it could be a queuing service like RabbitMQ. It could be any memory cache like Redis. It could be S3, Google Cloud Storage, Dropbox, what have you, any number of different services to store that information, put it in a service, don’t rely on any application to do it.
Also, when connecting to your application, you need to remember that HTTP and HTTPS sessions are not persisted or replicated between the instances. Once they’re talking to a particular instance, that’s what they talk to for the period of time they’re operating and if that instance goes away, any of that state would go away as well. You can do sticky sessions if you want to, it’s not a great [patent 00:02:57], I don’t recommend sticky sessions in general because again, it reduces flexibility, but you can implement it using the JSESSIONSID cookie if you want to, so that keeps you with some affinity to the instance that you’re talking to.
Really, if you want to have some sort of state or session persistence across instances, you need to use an external services to do that. There are lots of open source projects that do that and lots of frameworks that support those natively as well. Also, when connecting to your application from an end user perspective, remember there are two and only two ports you’ll be doing that over. Port 80 and port 443, respectively, HTTP and HTTPS, and certainly the current trend du jour is to do everything over HTTPS and these days with performance being what it is, why wouldn’t you, so that’s what you want to do.
Also, when you’re sending your data up to the platform, make sure you’re only sending the bits that you need. It’s actually very easy to accidentally send log files and temp files, et cetera, from your development environment up onto your platform. It’s a waste of space, you don’t need to do it, it’s a waste of time, you don’t need to do it. It’s very easy to avoid doing that using the .tfignore file, which you can define which files should not be pushed up to the platform. Works pretty similar to the way .gitignore file works as well.
Also, obviously if you’re using a language that is supported by Pivotal CF, then you can use a build pack, and a build pack is really a bundle of detection and configuration scripts that will provide framework and runtime support for your application, so it knows all the bits and pieces that need to be brought together.
Let’s get into the meat. What is the deployment process? Basically, it’s a command. It’s a command that we … A lot of it’s called CF push and what does CF push do? Basically it does the following. It will upload and store the application files from your local environment onto the platform. It will examine and store any of the application metadata. It will then create a droplet for the application and this droplet is the name that we use for the Cloud Foundry unit of execution. This is the component that will be deployed within the containers running on the platform.
It will then select an appropriate droplet execution agent or DEA to run the droplet, so the place in which the droplet will run becomes an instance, and then the application itself will start. All that happens behind the scenes automagically, basically you watch it on the screen [inaudible 00:05:31] to CF Push and you go from the CF push command to running application in very short order.
Let’s dive into those steps in a little more detail. The first thing is to make sure that you’re ready to deploy. As I mentioned, make sure that your application meets those requirements from a cloud-ready perspective. Once you’ve done that, you’re good to go. The next thing you need to do is to basically log on to the particular end point that you’re pointing to. This will be the API end point for your particular Cloud Foundry Instance. It’s also known as a target URL. It will be known to you, you’ll have a username and a login ID and a password, so you just simply point in the right direction so you can point and shoot as it were.
If you need to configure a custom domain, this is also the point to do that, although all Cloud Foundry instances will have a default domain available to it so you can just leverage that. Then you want to specify your deployment options. Again, these are just some of the metadata pieces of information. Simple things like the name of the application, how many instances you want it to run, how much memory it will use, any start command information required, any services you wanted to bind to, et cetera.
You can also define these particular options on the command line. You can also use what’s called a manifest file. This is if you’re defining these options on a regular basis or you know the services that the application needs to consume, you can define those in the manifest file, which will travel up with all the other bits and pieces belonging to the application and will configure it automatically.
Once you’ve done that, again, you do the fun bit, which is basically typing in CF space push, space application name. Once you do that, it will do all those other steps we mentioned before. Collect all the data for the application, upload it onto the platform, get it prepared, get it all compile and assembled and ready to go, and execute it on the designed number of instance that you have for your particular application. If you said you like to run instance, it will run it on one, if you say you want to run it on 10 instances, it will run it on 10 and will load balance across all those for you.
One of the deceptively pleasing and simple parts is just how quick that process is, and it is that CF push process that is really encapsulating a whole lot of complexity, a whole lot of traditional process that used to take place in many deployment environments wrapping it up into a fully automated, repeatable, and reliable process that takes the application from running successfully on my laptop to running successfully in the cloud in one simple step.
A simple thing but a deceptively powerful thing to keep in mind. That is all it takes to push an application. In fact, if you’d like to try that out, one option you have is something called Pivotal Web Services or PWS or P-Dubs as we like to call, and Pivotal Web Services is an Internet-based service that runs in the cloud naturally that you can log on to, you can create a free account for 30 days and deploy some applications and you can figure out how that push experience is for you. If you’ve got a local Java application you’re running or Ruby application or [inaudible 00:08:35] JS or [inaudible 00:08:36] one of the supported platforms, you can just push that up into the cloud as when you want to using Pivotal Web Services. That gives you that CF Push experience with zero setup time.
I hope that’s been useful, it’s been great to talk to you again, and look forward to having you to listening to other episodes that we have coming up, some technical ones coming up, some interviews coming up, some topics on platforms, some topics on data as we tend to [inaudible 00:09:03] and choose between the two. Hope you’re enjoying the content, love to get your feedback, podcast@pivotal.io is the address for that, we respond to all the feedback that we get and we action it, and look forward to having you listen again soon.
Thanks very much and until then, keep on [inaudible 00:09:19].
Speaker 1:
Thanks for listening to the All Things Pivotal Podcast. If you enjoyed it, please share it with others. We love hearing your feedback so please send any comments or suggestions to podcast@pivotal.io.
About the Author
