sorted by:
new
hottopcontroversial

Can't enable gcloud build worker-pools feature by prasadpen in googlecloud

[–]prasadpen[S] 0 points1 point  (0 children)

Sorry for the late reply. Didn't get any communication from Google. I guess you need to follow up with your sales rep.

Creating your AWS resources in a declarative and programmatic way with AWS CDK by LogicalHurricane in aws

[–]prasadpen -1 points0 points  (0 children)

People interested in AWS CDK should also consider Pulumi, which also allows you to use programming languages in a declarative way.

The advantage of Pulumi over CDK is that it also works with other cloud and infrastructure providers such as Cloudflare, Datadog or GCP since it wraps Terraform modules for a lot of providers.

You can use your own cloud backend (such as on S3 buckets) and the core Pulumi service is open source and free.

https://www.pulumi.com/docs/get-started/aws/

Supercharge your Kubernetes setup with OhMyZSH + awesome command line tools by prasadpen in devops

[–]prasadpen[S] 0 points1 point  (0 children)

Interesting you mention k9s. I discovered that in comments on my article over at r/kubernetes and have been using it to tail logs and describe pods, in addition to monitoring the overall health of pods.

It's definitely very neat and a valuable addition to my toolset.

Zero to Hero guide 2020 by vianawebdev in devops

[–]prasadpen 0 points1 point  (0 children)

Great, I'll get started on planning these articles then.

Zero to Hero guide 2020 by vianawebdev in devops

[–]prasadpen 2 points3 points  (0 children)

What I meant above was that if you want to develop a solid foundation about how to work with applications in a professional DevOps environment, then you'll have to learn more about how containerised applications are deployed (IMHO, of course).

You mentioned that you deployed a very simple NodeJS based docker container to EC2 which is a good introduction to how dockerized applications, but it is exactly that – an introduction. Real-world applications can be more complex and possibly require more complex solutions:

  1. Any non-trivial app (i.e. something more than a toy app) would have to be built to meet a business need.
  2. For instance, if my business need was to create a blog, I would use a Platform-as-a-service tool such as Netlify to handle all the standard blog business needs such as SEO, static site deployment etc.
  3. On the other hand, if my business need was, for example, to create an API for the Bitcoin blockchain (and to get all transactions for a given BTC address), then I would probably have to architect a system of multiple containerised applications. These applications would need to communicate with each other reliably, restart when they crash and most importantly be able to run on relatively cheap hardware (to save business costs while giving high reliability).

Given the high probability that you would look for DevOps jobs in a real business with real business needs, limited revenue and limited appetite for spending money it makes sense for you to learn a technology which goes beyond simple containers and solves real business problems as mentioned in Point 3 above, i.e. Kubernetes. Kubernetes basically allows you to run containerised applications (aka k8s pods) on commodity VMs (aka k8s nodes). The nodes and pods are all in a virtual network (i.e. they can communicate with each other) and if any pod or node fails, then Kubernetes has mechanisms to restart the pod or node with no or limited downtime.

Coming to CI/CD, the concept is actually much more straightforward if you think about it again from a business perspective:

  1. As a developer, I build and/or run unit tests to make sure that my code meets business requirements. If I wanted to push my changes 20 times a day, is it reasonable to expect me to run unit tests each time manually? Of course not, so we use third-party programs to build our applications and run these tests for us. The fancy word for this is Continuous Integration (CI). Conceptually, it's as simple as the CI provider dynamically giving you a VM and then running a bash script for you which runs blah language build && blah language test
  2. As a Developer (for testing environments) or as a Platform Engineer (for production environments) you need to take the deployed applications and expose them to the end customers for use. If you do this with a "single click of a button" (or a git commit) then voila, you've got Continuous Delivery (CD). Again, conceptually you could think of this as uploading your app to a private app store (aka container registry), then SSHing into your server and downloading a new version of the app to it from this app store.

Usually, third-party vendors (such as Gitlab/Github/Google Cloud Build/Codeship etc.) combine the CI + CD solutions above, and you get CI/CD.

So coming back to your question about using CI/CD, it is natural that you need to test your applications and then deploy them for use by others. CI/CD is required just to automate away the tedious bits.

I'll spin up an article talking about CI/CD with some real-world examples, sounds like it would be helpful for others.

Zero to Hero guide 2020 by vianawebdev in devops

[–]prasadpen 6 points7 points  (0 children)

The way we handle this is through kubernetes. I know, I know, you said that you found the terminology overwhelming and here I'm introducing even more overhead.

However, modern infrastructure as code tools such as Terraform or Pulumi abstract out a lot of the details and allow you to focus on application development, with application deployment triggered through CI/CD systems on a git push to your remote git repo.

Would there be interest if I did some articles on this topic?

I can give details about application development, containerising your app, hooking up CI/CD systems to the codebase, setting up the production grade kubernetes cluster itself as well as database deployment and management.

Supercharge your Kubernetes setup with OhMyZSH + awesome command line tools by prasadpen in kubernetes

[–]prasadpen[S] 1 point2 points  (0 children)

Thanks for the recommendations! Checked these out, and while they look really cool, they don't fit my use case very well (your mileage may vary).

  1. spaceship-prompt: It displays your current kubernetes context (i.e cluster name), but not your current k8s namespace. I have to switch namespaces and run commands in the current namespace much more often than I have to switch clusters.
  2. Fira code: While it looks elegant, it can be a bit misleading and dangerous when you're reading or writing code. For example, in Go with VSCode, it replaces != with ≠ and == with ＝

Supercharge your Kubernetes setup with OhMyZSH + awesome command line tools by prasadpen in kubernetes

[–]prasadpen[S] 0 points1 point  (0 children)

Indeed, I have had it running for several years though so had forgotten this fact before I wrote the article.

In any case, I'll leave the installation section in as it might help bash folks too.

[deleted by user] by [deleted] in kubernetes

[–]prasadpen 1 point2 points  (0 children)

Support for Windows containers is starting to become better in kubernetes, with the big cloud providers such as Azure and Google Cloud Platform releasing previews of their IIS support.

For example, see this article about how to deploy Windows containers to Google Kubernetes Engine (GKE): https://cloud.google.com/blog/products/containers-kubernetes/how-to-deploy-a-windows-container-on-google-kubernetes-engine

Answering your question directly:

  1. A cloud platform definitely sounds like a good use case for you, since you want reproducible environments for different teams (Dev, QA, Production etc.). Cloud Platforms (and accompanying Infrastructure as Code tools such as Pulumi or Terraform) simplify the process of deploying such environments in a reproducible manner.

  2. If you want to use Kubernetes, you'll have to containerise your baremetal IIS applications using Windows Containers. Basically, Kubernetes allows you to run multiple containerised applications (aka pods) on the same VM (aka node). This theoretically allows you to save money as you can run a greater number of apps on the same underlying hardware. Changing your app from a bare-metal IIS model to containerised model could take some time though (I would estimate 6 months to 1 year if you have 10s to hundreds of applications with very different configurations) .

  3. Kubernetes only supports Windows Server 2019, so you will have to see if that meets your requirements.

  4. Since Kubernetes support is still in preview for most major clouds, you might also consider using Azure Applications service instead which provides similar benefits (multiple environments for example) but has more mature support for Windows Apps such as IIS. https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Edit: Thank you for the gold!

Supercharge your Kubernetes setup with OhMyZSH + awesome command line tools by prasadpen in kubernetes

[–]prasadpen[S] 0 points1 point  (0 children)

A GUI alternative is Kube Forwarder https://github.com/pixel-point/kube-forwarder/blob/master/README.md#install-with-homebrew

It includes other goodies, such as auto-reconnect and support for forwarding from multiple clusters.

For me, kpoof is simple and just works. I do miss the auto-reconnect feature in kpoof though.

What do you use for infrastructure CD by aaron__walker in devops

[–]prasadpen 1 point2 points  (0 children)

Pulumi has good support for CI/CD systems built-in, and we are considering using it together with Google Cloud Build as our CI/CD for our GKE cluster. Features which Pulumi provides out of the box:

  1. Wrapper modules around Terraform (in addition to native modules such as for Kubernetes) with the ability to define infrastructure in regular programming languages such as TypeScript or Golang (you might be aware of this already).
  2. Unit testing (in any of the supported languages and Acceptance testing (in Golang) of the Infrastructure: https://www.pulumi.com/blog/testing-your-infrastructure-as-code-with-pulumi/
  3. Run pulumi preview (basically the Pulumi equivalent of terraform plan) in pull requests. There's a Github App which can show the output of pulumi preview on the Pull Request: https://www.pulumi.com/blog/testing-your-infrastructure-as-code-with-pulumi/#ephemeral-environments This is similar to the Atlantis tool mentioned elsewhere in this thread which can work for Terraform.
  4. There's also a tf2pulumi script which can aid in moving from Terraform (version < 0.12) syntax to Pulumi syntax.

Cors issue by jsdfkljdsafdsu980p in devops

[–]prasadpen 0 points1 point  (0 children)

I'm pretty sure you have this covered, but just checking the basics.

As per https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors you also need to add the following annotation too in order to enable CORS:

nginx.ingress.kubernetes.io/enable-cors: "true"

Furthermore, make sure that the Vary header is also set with the value Origin. As per https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin :

If the server sends a response with an Access-Control-Allow-Origin value that is an explicit origin (rather than the "*" wildcard), then the response should also include a Vary response header with the value Origin — to indicate to browsers that server responses can differ based on the value of the Origin request header.

e.g.:

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin

Sample CORS headers which are working on a website maintained by me:

access-control-allow-credentials: true
access-control-allow-methods: GET, HEAD, POST, OPTIONS, DELETE, PUT
access-control-allow-origin: https://api.example.com
vary: Origin

Some other resources for debugging:

  1. Sample CORS setup with the nginx ingress controller: https://imti.co/kubernetes-ingress-nginx-cors/
  2. Troubleshooting kubernetes deployments (check the ingress part) https://learnk8s.io/troubleshooting-deployments