ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Virtual appliances?

    IT Discussion
    virtual appliance ova vmware xen kvm hyper-v
    6
    27
    2.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • 1
      1337
      last edited by 1337

      What's your thoughts on virtual appliances?

      Do you prefer getting a custom iso / virtual image already set up, over installing an OS, packages and applications needed yourself?

      1 Reply Last reply Reply Quote 1
      • travisdh1T
        travisdh1
        last edited by travisdh1

        I prefer using an iso. Almost never is a virtual image easy to use with my preferred virtualization host platform (KVM or Xen), and if using an appliance I really don't want to d*** around with a base OS first.

        1 scottalanmillerS 2 Replies Last reply Reply Quote 3
        • 1
          1337 @travisdh1
          last edited by 1337

          @travisdh1 said in Virtual appliances?:

          I prefer using an iso. Almost never is a virtual image easy to use with my preferred virtualization host platform (KVM or Xen), and if using an appliance I really don't want to d*** around with a base OS first.

          I like iso myself too as I've had some bad luck with ready-to-run images in the past. There always seems to be some kind of issue with different network drivers or installed guest additions.

          I don't know the current status of ova files though. Is that the current standard for distributing virtual appliances that are supposed to run on every common virtualization platform? Or what just in theory?

          scottalanmillerS 1 Reply Last reply Reply Quote 1
          • stacksofplatesS
            stacksofplates
            last edited by

            This day and age Id just prefer a container. They're so much easier to deploy and manage.

            JaredBuschJ 1 Reply Last reply Reply Quote 2
            • JaredBuschJ
              JaredBusch @stacksofplates
              last edited by

              @stacksofplates said in Virtual appliances?:

              This day and age Id just prefer a container. They're so much easier to deploy and manage.

              Only when done right, which is still not often, IMO.

              stacksofplatesS 2 Replies Last reply Reply Quote 1
              • stacksofplatesS
                stacksofplates @JaredBusch
                last edited by stacksofplates

                @JaredBusch said in Virtual appliances?:

                @stacksofplates said in Virtual appliances?:

                This day and age Id just prefer a container. They're so much easier to deploy and manage.

                Only when done right, which is still not often, IMO.

                That argument could be made for pretty much anything though. I think even on a single host it's easier to manage.

                scottalanmillerS 1 Reply Last reply Reply Quote 1
                • stacksofplatesS
                  stacksofplates
                  last edited by

                  I think it's more of the application now. If it was something designed for Windows 2003 and you put it in a container it wouls be terrible, but it would also be terrible installed normally. K8s is so easy to set up now that it's trivial to get things going. Even if you just use podman and systemd I think it's a step above installing the application in a VM.

                  travisdh1T 1 Reply Last reply Reply Quote 0
                  • stacksofplatesS
                    stacksofplates @JaredBusch
                    last edited by

                    @JaredBusch said in Virtual appliances?:

                    @stacksofplates said in Virtual appliances?:

                    This day and age Id just prefer a container. They're so much easier to deploy and manage.

                    Only when done right, which is still not often, IMO.

                    Btw not trying to argue with you. People def do it wrong. I'm just saying I've seen them do it wrong with VMs too.

                    JaredBuschJ scottalanmillerS 2 Replies Last reply Reply Quote 0
                    • travisdh1T
                      travisdh1 @stacksofplates
                      last edited by

                      @stacksofplates said in Virtual appliances?:

                      I think it's more of the application now. If it was something designed for Windows 2003 and you put it in a container it wouls be terrible, but it would also be terrible installed normally. K8s is so easy to set up now that it's trivial to get things going. Even if you just use podman and systemd I think it's a step above installing the application in a VM.

                      I need to try out K8s again. The first time I tried using it was early days and a pain. From what your saying it's a lot better/easier now.

                      stacksofplatesS 1 Reply Last reply Reply Quote 0
                      • JaredBuschJ
                        JaredBusch @stacksofplates
                        last edited by

                        @stacksofplates said in Virtual appliances?:

                        @JaredBusch said in Virtual appliances?:

                        @stacksofplates said in Virtual appliances?:

                        This day and age Id just prefer a container. They're so much easier to deploy and manage.

                        Only when done right, which is still not often, IMO.

                        Btw not trying to argue with you. People def do it wrong. I'm just saying I've seen them do it wrong with VMs too.

                        Oh I completely understand. Docker is super abused though.

                        stacksofplatesS 1 Reply Last reply Reply Quote 2
                        • scottalanmillerS
                          scottalanmiller @travisdh1
                          last edited by

                          @travisdh1 said in Virtual appliances?:

                          I prefer using an iso. Almost never is a virtual image easy to use with my preferred virtualization host platform (KVM or Xen), and if using an appliance I really don't want to d*** around with a base OS first.

                          I agree, if you are going to do this, I need an ISO.

                          1 Reply Last reply Reply Quote 1
                          • scottalanmillerS
                            scottalanmiller @stacksofplates
                            last edited by

                            @stacksofplates said in Virtual appliances?:

                            @JaredBusch said in Virtual appliances?:

                            @stacksofplates said in Virtual appliances?:

                            This day and age Id just prefer a container. They're so much easier to deploy and manage.

                            Only when done right, which is still not often, IMO.

                            Btw not trying to argue with you. People def do it wrong. I'm just saying I've seen them do it wrong with VMs too.

                            True, anything can be screwed up.

                            1 Reply Last reply Reply Quote 0
                            • scottalanmillerS
                              scottalanmiller @stacksofplates
                              last edited by

                              @stacksofplates said in Virtual appliances?:

                              @JaredBusch said in Virtual appliances?:

                              @stacksofplates said in Virtual appliances?:

                              This day and age Id just prefer a container. They're so much easier to deploy and manage.

                              Only when done right, which is still not often, IMO.

                              That argument could be made for pretty much anything though. I think even on a single host it's easier to manage.

                              True. I think the problem is that Docker feels like it's never set up correctly for third party application deployments. As a tech it's amazing, in the real world, it seems to result it devs bypassing all operational oversight and apps that have good code and no production way to deploy.

                              stacksofplatesS 1 Reply Last reply Reply Quote 2
                              • scottalanmillerS
                                scottalanmiller @1337
                                last edited by

                                @Pete-S said in Virtual appliances?:

                                @travisdh1 said in Virtual appliances?:

                                I prefer using an iso. Almost never is a virtual image easy to use with my preferred virtualization host platform (KVM or Xen), and if using an appliance I really don't want to d*** around with a base OS first.

                                I like iso myself too as I've had some bad luck with ready-to-run images in the past. There always seems to be some kind of issue with different network drivers or installed guest additions.

                                I don't know the current status of ova files though. Is that the current standard for distributing virtual appliances that are supposed to run on every common virtualization platform? Or what just in theory?

                                Yup, exactly. Consistently I still need OS control. Whether VM or container, that never works.

                                1 Reply Last reply Reply Quote 1
                                • stacksofplatesS
                                  stacksofplates @scottalanmiller
                                  last edited by

                                  @scottalanmiller said in Virtual appliances?:

                                  @stacksofplates said in Virtual appliances?:

                                  @JaredBusch said in Virtual appliances?:

                                  @stacksofplates said in Virtual appliances?:

                                  This day and age Id just prefer a container. They're so much easier to deploy and manage.

                                  Only when done right, which is still not often, IMO.

                                  That argument could be made for pretty much anything though. I think even on a single host it's easier to manage.

                                  True. I think the problem is that Docker feels like it's never set up correctly for third party application deployments. As a tech it's amazing, in the real world, it seems to result it devs bypassing all operational oversight and apps that have good code and no production way to deploy.

                                  What do you mean about third party applications? That's pretty much what most people use it for unless you're an enterprise and writing micro services.

                                  There isn't any need for operational oversight of devs because it's all done through things like merge/pull requests. Then tools like Flux/Argo/whatever deploy it for you.

                                  I'm not sure what you mean about no production way to deploy. Automated pipelines are a more production way that just installing packages in systems. You have easier rollback, easier ways to apply seccomp profiles, resources, etc. Its very production ready.

                                  1 scottalanmillerS 2 Replies Last reply Reply Quote 0
                                  • stacksofplatesS
                                    stacksofplates @travisdh1
                                    last edited by

                                    @travisdh1 said in Virtual appliances?:

                                    @stacksofplates said in Virtual appliances?:

                                    I think it's more of the application now. If it was something designed for Windows 2003 and you put it in a container it wouls be terrible, but it would also be terrible installed normally. K8s is so easy to set up now that it's trivial to get things going. Even if you just use podman and systemd I think it's a step above installing the application in a VM.

                                    I need to try out K8s again. The first time I tried using it was early days and a pain. From what your saying it's a lot better/easier now.

                                    For remote systems, k3s is probably easiest.

                                    curl -sfL https://get.k3s.io | sh - Run that and you have k8s.

                                    For local work, kind is probably easiest. It runs containers as k8s nodes that then run Docker so you can deploy to them. It works really well.

                                    1 Reply Last reply Reply Quote 0
                                    • 1
                                      1337 @stacksofplates
                                      last edited by

                                      @stacksofplates said in Virtual appliances?:

                                      @scottalanmiller said in Virtual appliances?:

                                      @stacksofplates said in Virtual appliances?:

                                      @JaredBusch said in Virtual appliances?:

                                      @stacksofplates said in Virtual appliances?:

                                      This day and age Id just prefer a container. They're so much easier to deploy and manage.

                                      Only when done right, which is still not often, IMO.

                                      That argument could be made for pretty much anything though. I think even on a single host it's easier to manage.

                                      True. I think the problem is that Docker feels like it's never set up correctly for third party application deployments. As a tech it's amazing, in the real world, it seems to result it devs bypassing all operational oversight and apps that have good code and no production way to deploy.

                                      What do you mean about third party applications? That's pretty much what most people use it for unless you're an enterprise and writing micro services.

                                      There isn't any need for operational oversight of devs because it's all done through things like merge/pull requests. Then tools like Flux/Argo/whatever deploy it for you.

                                      I'm not sure what you mean about no production way to deploy. Automated pipelines are a more production way that just installing packages in systems. You have easier rollback, easier ways to apply seccomp profiles, resources, etc. Its very production ready.

                                      I think there is a big difference in the production environment of say a SaaS company compared to the rest of the companies that are not in the software business.

                                      CI/CD pipelines seems highly unlikely in a company that doesn't develop software or provide software services. Why would they have that?

                                      If you have enough workloads you need automation tools to deploy patches and administrate your environment but that is a different thing and something all environments of size needs.

                                      stacksofplatesS 1 Reply Last reply Reply Quote 0
                                      • stacksofplatesS
                                        stacksofplates @1337
                                        last edited by stacksofplates

                                        @Pete-S said in Virtual appliances?:

                                        @stacksofplates said in Virtual appliances?:

                                        @scottalanmiller said in Virtual appliances?:

                                        @stacksofplates said in Virtual appliances?:

                                        @JaredBusch said in Virtual appliances?:

                                        @stacksofplates said in Virtual appliances?:

                                        This day and age Id just prefer a container. They're so much easier to deploy and manage.

                                        Only when done right, which is still not often, IMO.

                                        That argument could be made for pretty much anything though. I think even on a single host it's easier to manage.

                                        True. I think the problem is that Docker feels like it's never set up correctly for third party application deployments. As a tech it's amazing, in the real world, it seems to result it devs bypassing all operational oversight and apps that have good code and no production way to deploy.

                                        What do you mean about third party applications? That's pretty much what most people use it for unless you're an enterprise and writing micro services.

                                        There isn't any need for operational oversight of devs because it's all done through things like merge/pull requests. Then tools like Flux/Argo/whatever deploy it for you.

                                        I'm not sure what you mean about no production way to deploy. Automated pipelines are a more production way that just installing packages in systems. You have easier rollback, easier ways to apply seccomp profiles, resources, etc. Its very production ready.

                                        I think there is a big difference in the production environment of say a SaaS company compared to the rest of the companies that are not in the software business.

                                        CI/CD pipelines seems highly unlikely in a company that doesn't develop software or provide software services. Why would they have that?

                                        If you have enough workloads you need automation tools to deploy patches and administrate your environment but that is a different thing and something all environments of size needs.

                                        SaaS companies aren't the only ones with internal development. Pretty much any fortune 1000 and up has that.

                                        But yes pipelines are mostly for internal development. But you also can just deploy containers the same way. If you aren't using a CD tool to deploy the update containers automatically, you would have a merge/pull request with the new container tag. The same idea applies, just not with the CI part.

                                        Its not about enough workloads to automate deployment. It takes almost no effort to automate container deployments. You run a helm install command against your cluster to set Flux up and then have it read a couple yaml files. Its less work to do that than update software the old way.

                                        1 Reply Last reply Reply Quote 1
                                        • stacksofplatesS
                                          stacksofplates @JaredBusch
                                          last edited by

                                          @JaredBusch said in Virtual appliances?:

                                          @stacksofplates said in Virtual appliances?:

                                          @JaredBusch said in Virtual appliances?:

                                          @stacksofplates said in Virtual appliances?:

                                          This day and age Id just prefer a container. They're so much easier to deploy and manage.

                                          Only when done right, which is still not often, IMO.

                                          Btw not trying to argue with you. People def do it wrong. I'm just saying I've seen them do it wrong with VMs too.

                                          Oh I completely understand. Docker is super abused though.

                                          What do you mean by abused?

                                          scottalanmillerS 1 Reply Last reply Reply Quote 0
                                          • stacksofplatesS
                                            stacksofplates
                                            last edited by stacksofplates

                                            Here's an example. To set up Flux you run these couple commands:

                                            helm repo add fluxcd https://charts.fluxcd.io

                                            kubectl apply -f https://raw.githubusercontent.com/fluxcd/helm-operator/master/deploy/crds.yaml

                                            kubectl create namespace flux

                                            helm upgrade -i flux fluxcd/flux \
                                               --set [email protected]:user/some-repo \
                                               --namespace flux
                                            

                                            that sets up Flux. Flux is now watching the repo you told it there in the last command.

                                            If you don't use a predefined key, you just grab the SSH key Flux created and add it to your repo.

                                            Then to deploy something like NextCloud, you need these two files. The first creates a namespace for nextcloud. Not a requirement, but makes sense. The second is a HelmRelease file that the Flux Helm Operator uses to read the Helm chart for NextCloud.

                                            apiVersion: v1
                                            kind: Namespace
                                            metadata:
                                              name: nextcloud
                                            
                                            apiVersion: helm.fluxcd.io/v1
                                            kind: HelmRelease
                                            metadata:
                                              name: nextcloud
                                              namespace: nextcloud
                                              annotations:
                                                fluxcd.io/automated: "true"
                                                filter.fluxcd.io/chart-image: "glob:*"
                                            spec:
                                              releaseName: nextcloud
                                              chart:
                                                repository: https://nextcloud.github.io/helm/
                                                name: nextcloud
                                              values:
                                                replicaCount: 2
                                                any other values here to override in the chart
                                            

                                            that's it. You now have a fully automated system that will automatically deploy the new updates to your NextCloud pods. You can disable the auto updates by removing the annotations and then manually update the container versions by adding the version in the HelmRelease. Once it's approved, then Flux will update the containers.

                                            You also have have a deployment that created a replicaset of your pod because you defined 2 for your replicacount. So any traffic entering your cluster will be split between both replicas (or more if you define more). By default, k8s does a rolling update. So pods aren't all killed at once. The first pod will be terminated and a new one spun up with the updates. When it's live, the second will be terminated and recreated with the updates. So your service stays live during updates.

                                            It's that easy. It shouldn't take you more than 10 minutes to set Flux up. And then the rest is the specific things you need the apps to do. Like with NextCloud the type of database, if you want ingress or not, those kinds of options.

                                            Containers and container orchestrators help literally every business from small to giant enterprises developing hundreds to thousands of internal microservices.

                                            I don't even have some things installed on my system anymore. I'll just run a container to use a specific tool and kill the container when I'm done. You can even have full dev environments packaged up in a contianer and have VSCode deploy itself in the container so you have a consistent development environment across different users. And that happens literally with the push of a button in VSCode.

                                            travisdh1T 1 Reply Last reply Reply Quote 1
                                            • 1
                                            • 2
                                            • 1 / 2
                                            • First post
                                              Last post