{"id":3291,"date":"2022-02-11T13:20:28","date_gmt":"2022-02-11T01:20:28","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=3291"},"modified":"2022-02-11T13:20:32","modified_gmt":"2022-02-11T01:20:32","slug":"kubernetes-home-load-balancer","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/3291\/","title":{"rendered":"Kubernetes @ Home: Load Balancer"},"content":{"rendered":"[Estimated Reading Time: <\/span> 10<\/span> minutes]<\/span><\/span>\n

In the previous post<\/a> we installed the Kubernetes Dashboard<\/strong> and saw how we could access the dashboard service which itself runs in the Kubernetes<\/strong> cluster. We also saw how clunky that was and I promised a better way, which we turn to now.<\/p>\n\n\n\n\n\n\n\n

Kubernetes Services and IP Addresses<\/h2>\n\n\n\n

To this point, we have installed the Kubernetes Dashboard<\/strong> with the default IP configuration. Which is to say that the alternative.yaml<\/mark> file provided no configuration in this respect and so was endowed with the default.<\/p>\n\n\n\n

As a result, the dashboard service is assigned a ClusterIP<\/strong>.<\/p>\n\n\n\n

If we look again at the list of all services in my cluster:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We see that all<\/em> of these services have a CLUSTER-IP<\/mark><\/strong>.<\/p>\n\n\n\n

This is an IP address from the pool of IP addresses reserved for the internal network within the cluster<\/em>. Configured in this way, the service is accessible only from within the cluster (or via kubeproxy<\/strong> or port-forwarding, as we saw previously<\/a>).<\/p>\n\n\n\n

The options in this area are as follows:<\/p>\n\n\n\n

ClusterIP<\/strong><\/td>Assigned an IP in the cluster network for access within the cluster. To access the Service<\/strong> from outside the cluster, kubeproxy<\/strong> or port-forwarding must be used.<\/td><\/tr>
NodePort<\/strong><\/td>Establishes a port-forwarding rule on every<\/em> worker node. To access the Service<\/strong> from outside the cluster, use the specified port on any<\/em> of the worker nodes.<\/td><\/tr>
LoadBalancer<\/strong><\/td>Provides an IP address that may be used to access the Service from outside the cluster.<\/td><\/tr>
ExternalName<\/strong><\/td>Establishes a Service that resolves to a different DNS name.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The descriptions of these above are highly simplified, but we won’t be looking at all of these in detail.<\/p>\n\n\n\n

ClusterIP<\/strong> we have already covered, with one final note to mention that in a micro-services architecture where a consumable service may be supported by a number of “background” services that a client application does not interact with directly, ClusterIP<\/strong> is perfectly adequate for those background services.<\/p>\n\n\n\n

LoadBalancer<\/strong> is what I will use to provide access to my dashboard (and other services) from outside the cluster and what we will look at next. Although technically this mechanism also establishes NodePorts<\/strong>, this is an internal implementation detail that we will not need to be concerned with.<\/p>\n\n\n\n

For those that are interested Arseny Zinchenko has an excellent detailed discussion of them<\/a>.<\/p>\n\n\n\n

In the list of services in the cluster, only the kubernetes-dashboard<\/strong> service has an EXTERNAL-IP<\/mark><\/strong>. This is because the kubernetes-dashboard<\/strong> is configured with the LoadBalancer<\/mark><\/strong> type.<\/p>\n\n\n\n

So let’s see how this is achieved.<\/p>\n\n\n\n

Configuring a Load Balancer<\/h2>\n\n\n\n

Actually configuring a service to use a LoadBalancer<\/strong> is trivial, involving only specifying the required type in the service descriptor. If we look again at that descriptor:<\/p>\n\n\n\n

kind: Service\napiVersion: v1\nmetadata:\n  labels:\n    k8s-app: kubernetes-dashboard\n  name: kubernetes-dashboard\n  namespace: kubernetes-dashboard\nspec:\n  ports:\n    - port: 80\n      targetPort: 9090\n  selector:\n    k8s-app: kubernetes-dashboard<\/code><\/pre>\n\n\n\n
The part we need to change (or rather, add to) is the spec<\/strong>.  We simply add a type<\/strong> entry with the value LoadBalancer<\/strong>:<\/p>\n\n\n\n
kind: Service\napiVersion: v1\nmetadata:\n  labels:\n    k8s-app: kubernetes-dashboard\n  name: kubernetes-dashboard\n  namespace: kubernetes-dashboard\nspec:\n  type: LoadBalancer\n  ports:\n    - port: 80\n      targetPort: 9090\n  selector:\n    k8s-app: kubernetes-dashboard<\/code><\/pre>\n\n\n\n
And that’s it.<\/p>\n\n\n\n
But Kubernetes<\/strong> does not provide a LoadBalancer<\/strong> by default.  In a cloud context, this would usually be provided by the cloud provider.  But in a Bare Metal<\/strong> cluster we need to install one ourselves.<\/p>\n\n\n\n
This is where MetalLB<\/a><\/strong> comes in.<\/p>\n\n\n\n
If we were to apply this service descriptor without a LoadBalancer<\/strong> installed, the service will be assigned a CLUSTER-IP<\/strong>, but the EXTERNAL-IP<\/em><\/strong> will be stuck in a Pending<\/strong> state.<\/p>\n\n\n\n
So let’s install MetalLB<\/strong>.<\/p>\n\n\n\n
Installing The MetalLB LoadBalancer<\/h2>\n\n\n\n
Installation of MetalLB consists of essentially two steps:<\/p>\n\n\n\n
  1. Install MetalLB itself<\/li>
  2. Install a ConfigMap<\/li><\/ol>\n\n\n\n
    The first is again trivially simple.<\/p>\n\n\n\n
    Two manifests are installed, the first establishes the metallb-system<\/strong> namespace while the second installs all the required MetalLB<\/strong> components into that namespace.  This provides everything needed for MetalLB<\/strong> to run.<\/p>\n\n\n\n
    We can verify this by listing pods in the metallb-system<\/strong> namespace:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    We see a controller<\/strong> and 4 speaker<\/strong>s.  There is a speaker<\/strong> on each node that is involved in advertising mechanisms, with a single controller<\/strong> that is the piece responsible for actually allocating IP addresses.<\/p>\n\n\n\n
    So MetalLB<\/strong> is running, but it isn’t doing anything useful at this point as we have not told it anything about the network environment it is running in. <\/p>\n\n\n\n
    To have MetalLB<\/strong> do useful work, we need to provide some further information.<\/p>\n\n\n\n
    Conveniently all of this is externalised in a separate ConfigMap<\/strong> object.  To change the configuration of MetalLB<\/strong>, all that is required is to update and reapply this ConfigMap<\/strong>.<\/p>\n\n\n\n
    Configuring MetalLB: Layer2 or BGP<\/h2>\n\n\n\n
    As described in the (excellent) documentation<\/a>, MetalLB<\/strong> can be configured to work in one of two ways (plus variations when taking into account “advanced” configuration):<\/p>\n\n\n\n
    Layer2<\/strong><\/td>The simplest to configure, you simply allocate a range of IP addresses for MetalLB to assign to services.  Should work with any router on any network.

    In this configuration, your service IP addresses are in the same subnet as the rest of your network (assuming you have a single subnet).<\/td><\/tr>
    BGP<\/strong><\/td>BGP (or Border Gateway Protocol<\/a>) is more sophisticated with a number of advantages over Layer2<\/strong>.  But it is also more complicated to configure and requires a router that supports BGP (and not all do).

    In this configuration, service IP addresses can be allocated on an entirely separate subnet to your main network.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    I opted for BGP and this is what my ConfigMap<\/strong> looks like:<\/p>\n\n\n\n
    apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: config\n  namespace: metallb-system\ndata:\n  config: |\n    peers:\n    - peer-address: 192.168.1.1\n      peer-asn: 64512\n      my-asn: 64512\n    address-pools:\n    - name: bgp\n      protocol: bgp\n      addresses:\n      - 10.10.10.10-10.10.10.250<\/code><\/pre>\n\n\n\n
    The ConfigMap<\/strong> object itself is very straightforward.  It provides a single value (config<\/strong>) which is itself a YAML document that provides the configuration.<\/p>\n\n\n\n
    To understand the configuration, this simplified schematic of the desired state of my (logical) network may help: <\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    USG is my UniFi Security Gateway<\/strong> router.<\/p>\n\n\n\n
    As mentioned before, I already have a number of VLANS’s configured in my router configuration, though not all of them are shown, for simplicity.<\/p>\n\n\n\n
    The three of interest here are:<\/p>\n\n\n\n
    Subnet<\/strong><\/td>Domain<\/strong><\/td>Purpose\/Description<\/strong><\/td><\/tr>
    192.168.1.0\/24<\/strong><\/td>.local<\/td>Used for my primary networking needs. This is where my dev workstations hang out, for example.<\/td><\/tr>
    10.10.0.0\/24<\/strong><\/td>.k8s<\/td>The subnet for the VM’s in my Kubernetes Cluster<\/strong>.

    NOTE: <\/strong>This is NOT<\/strong> the subnet of the pod network<\/strong> that runs inside<\/em> the cluster.  The pod network is entirely private – the wider network, including the USG, knows nothing of that network.<\/td><\/tr>
    10.10.10.0\/24<\/strong><\/td>.service<\/td>This is the new subnet for (external) IP’s allocated to services running in the Kubernetes Cluster<\/strong>, that will be managed by the MetalLB<\/strong> LoadBalancer<\/strong>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    To be clear: The schematic above is a logical<\/strong> representation of these networks.  MetalLB<\/strong> itself runs inside<\/em> the Kubernetes Cluster remember.<\/p>\n\n\n\n
    Returning to the ConfigMap<\/strong>.<\/p>\n\n\n\n
    The peer-address<\/strong> (from the MetalLB) perspective, is the gateway for the primary network on the USG, hence 192.168.1.1<\/strong>.<\/p>\n\n\n\n
    The two ASN<\/strong>s (Autonomous System Numbers) are ID’s for each peer in the relationship (“me” and “the other peer”).  You will notice that they are the same for reasons that I honestly do not understand.  I instinctively felt they should be different but this did not seem to work and all the guidance I found used the same ASN for each peer, and this works, so… \u00af\\_(\u30c4)_\/\u00af<\/p>\n\n\n\n
    Finally, the pool of IP addresses is defined, along with the fact that the BGP protocol is in use.<\/p>\n\n\n\n
    With this ConfigMap<\/strong> applied the MetalLB LoadBalancer<\/strong> will spring into life and start allocating External IP addresses to Services<\/strong> that require them (i.e. of type LoadBalancer<\/strong>).<\/p>\n\n\n\n
    But this isn’t enough.<\/p>\n\n\n\n
    When using BGP<\/strong>, each peer in the relationship needs to know about the other.  We’ve configured MetalLB<\/strong> with the required knowledge of the UniFi Security Gateway (USG).  But the USG also needs to be configured with knowledge of MetalLB.  Simply defining the network on the USG is not enough.<\/p>\n\n\n\n
    The USG does not know which hosts are actually allocated IP’s on that network – only MetalLB knows that.  USG knows that the network exists and now needs to be told that traffic destined for that network needs to be sent to MetalLB.<\/p>\n\n\n\n
    Unlike the creation of networks, the USG has no UI for BGP configuration.  Fortunately, configuring BGP on the USG is almost as straightforward as configuring MetalLB.<\/p>\n\n\n\n
    But it will first help to understand a little about how such configuration is applied.<\/p>\n\n\n\n
    UniFi Device Provisioning<\/h2>\n\n\n\n
    In a UniFi network, there is a Controller<\/a><\/strong> which – among other things – holds the network configuration and provides a pretty slick UI for managing (most aspects of) the network, to an advanced level.  The Controller<\/strong> software is free and can be run on any computer on the network.<\/p>\n\n\n\n
    In my case, I run a UniFi CloudKey device<\/a> which is a Linux system in a convenient, efficient and small form-factor that draws all the power it needs over PoE.<\/p>\n\n\n\n
    All UniFi managed devices (WiFi access points, switches, cameras, etc) go through a process called “provisioning” when booting up.  This provisioning process involves loading their configuration from the Controller<\/strong>.<\/p>\n\n\n\n
    In addition to that configuration which is possible through the UI, the Controller also provides additional configuration to specific devices from pre-defined files.<\/p>\n\n\n\n
    So, if you know what you are doing, you can upload configuration files to the prescribed location on the Controller<\/strong> to be provided to the requisite devices when they are provisioned.<\/p>\n\n\n\n
    It is important to do things this way.

    Everything that can be achieved through these configuration files can also usually be performed by issuing specific commands on each device (over an SSH session), but almost all configuration changes made in this way will be lost when that device reboots and is re-provisioned.

    “Fine, so don’t reboot them<\/em>“.

    Power outages happen and Ubiquiti are constantly pushing out firmware updates, which also require a reboot and\/or re-provisioning after they are applied.<\/p>\n\n\n\n
    USG Configuration<\/h2>\n\n\n\n
    Additional configuration for the UniFi Security Gateway<\/strong> is held in a file called config.gateway.json<\/mark>.  The location of this file on the Controller<\/strong> depends on the controller itself (it is different for a CloudKey vs a self-hosted installation on a PC, for example).  The name of the file is also prescribed: specific files are provided to specific devices during provisioning.<\/p>\n\n\n\n
    As well as the BGP configuration, this file is also where static host-IP allocations can be made.<\/p>\n\n\n\n
    In my case, this is where I establish the k8s-dashboard<\/strong> hostname for the IP allocated to the kubernetes-dashboard<\/strong> service in my cluster:<\/p>\n\n\n\n
    {\n    "protocols": {\n        "bgp": {\n            "64512": {\n                "neighbor": {\n                    "10.10.0.200": {\n                        "remote-as": "64512"\n                    },\n                    "10.10.0.101": {\n                        "remote-as": "64512"\n                    },\n                    "10.10.0.102": {\n                        "remote-as": "64512"\n                    },\n                    "10.10.0.103": {\n                        "remote-as": "64512"\n                    }\n                },\n                "parameters": {\n                    "router-id": "192.168.1.1"\n                }\n            }\n        }\n    },\n    "system": {\n        "static-host-mapping": {\n            "host-name": {\n                "k8s-dashboard.service": {\n                    "alias": [\n                        "k8s-dashboard"\n                    ],\n                    "inet": [\n                        "10.10.10.10"\n                    ]\n                }\n            }\n        }\n    }\n}<\/code><\/pre>\n\n\n\n
    The Controller<\/strong> UI allows for static IP’s to be assigned to MAC addresses but frustratingly does not provide a means of assigning an IP to a hostname (except where the corresponding host has a MAC address).<\/p>\n\n\n\n
    Having already seen the MetalLB<\/strong> ConfigMap<\/strong>, this configuration should make some sense.<\/p>\n\n\n\n
    There is a protocols<\/strong> object which in turn contains a bgp<\/strong> object.  This contains an object named 64512<\/strong>, which you may recall is the ASN<\/strong> of both the USG and MetalLB.  From what follows we can determine that this object name is the ASN<\/strong> of the USG.<\/p>\n\n\n\n
    Within this 64512<\/strong> object are a neighbour<\/strong> object and a parameters<\/strong> object.<\/p>\n\n\n\n
    The parameters<\/strong> object identifies the USG’s gateway IP address, while the neighbour<\/strong> object contains multiple objects, one for each of the nodes<\/em> in the Kubernetes Cluster<\/strong> (each of which has a remote-as<\/strong> property of 64512<\/strong> which we can deduce is the ASN of the remote peer – i.e. MetalLB<\/strong>).<\/p>\n\n\n\n
    At first glance this may not make much sense… this configuration is supposed to be sending traffic to MetalLB<\/em><\/strong> to be routed to pods within the Kubernetes cluster.  But it appears to be sending traffic to all of the nodes<\/strong><\/em>.<\/p>\n\n\n\n
    To be honest, I’m not 100% clear on this, but I think<\/em> the answer is that it’s doing both<\/em><\/strong>.<\/p>\n\n\n\n
    If I have understood things correctly, since we cannot know which node MetalLB<\/strong> is actually running on in the Cluster<\/strong>, we route traffic to all of the nodes.  In the case of three of those nodes, the traffic goes nowhere – a dead-end hop.  But on one of those nodes will be MetalLB<\/strong> which will then route the traffic accordingly.<\/p>\n\n\n\n
    Again, this currently falls into the category of things I have learned just enough to get working and don’t pretend to understand deeply.<\/p>\n\n\n\n
    In any event, after uploading this configuration file to the prescribed location using scp<\/strong>, the Controller<\/strong> UI can then be used to trigger the provisioning of the USG, so that this new configuration will be applied.<\/p>\n\n\n\n
    And we’re done!<\/p>\n\n\n\n
    The Results<\/h2>\n\n\n\n
    We’ve already seen what success looks like in the Kubernetes Cluster<\/strong>.  We have a service of type LoadBalancer<\/strong> that has been assigned an external IP address:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    On the USG side of things, we can check that the BGP configuration has been loaded successfully by logging in to the USG over SSH and issuing the command:<\/p>\n\n\n\n
    show ip bgp<\/pre>\n\n\n\n
    If all has gone well, you will see something similar to:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    This identifies the four neighbours that we established, with one of them marked as “best”.<\/p>\n\n\n\n
    Again, to be honest I’m not sure how this is determined to be the best.  I initially thought I would find that this was the node on which the MetalLB<\/strong> controller<\/strong> pod was running; that the controller<\/strong> was responding to whatever probes the BGP protocol uses to determine this “best” neighbour.  i.e. that worker1<\/strong> was running the controller and that the other nodes were the “dead-hops”.<\/p>\n\n\n\n
    But it turns out that the controller<\/strong> is running on worker2<\/strong>.  So, another \u00af\\_(\u30c4)_\/\u00af<\/p>\n\n\n\n
    The important thing is that when I nslookup<\/strong><\/mark> my k8s-dashboard.service<\/strong> host, I get the expected IP address:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    And, unsurprisingly given that result, if I type http:\/\/k8s-dashboard.service<\/mark> in my browser, I am taken to the Kubernetes Dashboard<\/strong>, can skip the signing-in process and see my cluster in all its glory:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Success!<\/p>\n\n\n\n
    As I deploy additional services into the Cluster<\/strong>, I shall need to do a little housekeeping to add additional static hostnames to my USG configuration for the services exposed via the MetalLB LoadBalancer<\/strong>.<\/p>\n\n\n\n
    But that’s a small price to pay and something I could probably automate if it becomes too onerous. \ud83d\ude42<\/p>\n\n\n\n
    In Summary<\/h2>\n\n\n\n
    That brings me to the end of this series on establishing a Kubernetes Cluster<\/strong> lab.<\/p>\n\n\n\n
    I appreciate that not all of it may be relevant to you in a different environment – particularly the UniFi networking aspects.  Hopefully, by sharing my goals and the steps to achieve them, you may have gained some insights – and perhaps some inspiration – for your own projects.<\/p>\n\n\n\n
    Do you have a Kubernetes Lab?<\/p>\n\n\n\n
    Do you run Kubernetes in the cloud?<\/p>\n\n\n\n
    Do you do\/have you done both<\/em>?<\/p>\n\n\n\n
    I’d love to hear your experiences in the comments.<\/p>\n\n\n\n
    Or perhaps you are wondering “Why go to all this trouble?<\/em>” \ud83d\ude42<\/p>\n\n\n\n
    On that last point, I have some projects lined up which will involve deployments into that cluster and may blog about those, which may help sell the idea.<\/p>\n","protected":false},"excerpt":{"rendered":"
    [Estimated Reading Time: <\/span> 10<\/span> minutes]<\/span><\/span> In the previous post we installed the Kubernetes Dashboard and saw how we could access the dashboard service which itself runs in the Kubernetes cluster. We also saw how clunky that was and I promised a better way, which we turn to now.<\/p>\n","protected":false},"author":2,"featured_media":3111,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"The concluding post in my short series on establishing a bare metal Kubernetes cluster: exposing a service to my network with a friendly hostname.","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4,321,1],"tags":[362,352,360,363,361],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-R5","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":3148,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3148\/","url_meta":{"origin":3291,"position":0},"title":"Kubernetes @ Home: PowerShell VM’s","date":"01 Feb 2022","format":false,"excerpt":"Following the Vagrant experiment (reminding me of a Bill Bailey metaphor... \"a long walk down a windy beach to a cafe that was closed\") I next set about automating my VM creation using PowerShell, with greater success. Though still not perfect, the final gap to full automation is something I\u2026","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3233,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3233\/","url_meta":{"origin":3291,"position":1},"title":"Kubernetes @ Home: Dashboard","date":"07 Feb 2022","format":false,"excerpt":"At the end of the previous post in this series, we reached the point where I had my Kubernetes cluster up and running, including a Dashboard service. As I mentioned, this Dashboard is not part of a default installation. Taking a look at how I got this up and running\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3076,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3076\/","url_meta":{"origin":3291,"position":2},"title":"A Kubernetes Cluster @ Home","date":"26 Jan 2022","format":false,"excerpt":"I set myself a new challenge for the New Year: Stand Up a Kubernetes cluster of my own. At home. I have reasons (long term costs being [potentially] lower than cloud-hosted alternatives being just one of them) but honestly since Kubernetes is a dominant presence in my day-to-day work these\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3099,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3099\/","url_meta":{"origin":3291,"position":3},"title":"Kubernetes @ Home: Vagrant Nodes","date":"27 Jan 2022","format":false,"excerpt":"The first significant practical step in establishing my Bare Metal Kubernetes cluster was to provision 4 VM's. At this point it is worth mentioning that actually installing Kubernetes is almost trivial once you have the necessary hardware in place. Since my 'hardware' was going to be virtual, this meant that\u2026","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/kubernetes-banner.png?fit=1171%2C416&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2983,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2983\/","url_meta":{"origin":3291,"position":4},"title":"Duget – PUSH-ing Packages","date":"25 Sep 2019","format":false,"excerpt":"We now know a little more about this duget thing, and have seen how to create a package. But a package cannot be consumed 'in situ' - it must be made available via a feed. Which brings us to the PUSH command.NOTE: Don\u2019t worry, I have my priorities straight. This\u2026","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":321,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/321\/","url_meta":{"origin":3291,"position":5},"title":"Delphi 2009 Trial – First Impressions","date":"11 Sep 2008","format":false,"excerpt":"I imagine the news has spread like wildfire - the Delphi 2009 Trial Edition is now available for download!\u00a0 I got me one, and these are my initial impressions. 1. The Installation The installer itself is a small downloader stub, so the initial download is very quick.\u00a0 During installation of\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3291"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=3291"}],"version-history":[{"count":7,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3291\/revisions"}],"predecessor-version":[{"id":3305,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/3291\/revisions\/3305"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media\/3111"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=3291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=3291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=3291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}